exclude defaults channel by default

[minrk]

make sure we're always using conda-forge by default

it's unlikely any packages came from defaults for users in some years (due to channel priority, this would only happen for packages not on conda-forge, and would often result in a broken env anyway), but this ensures defaults channel is opt-in, as it should be for the Anaconda ToS.

[rgaiacs]

What do you think of repo2docker to fail if user's provided environment.yml uses default Anaconda repository? Maybe have an option for this behaviour for the special case of mybinder.org.

[minrk]

I don't believe it is up to us. We could block egress to repo.anaconda.com, I suppose, but I don't think we need to. A user may install from the defaults channel and use it on mybinder.org if their use is permitted. mybinder.org doesn't enter into it, just like they can do on any cloud provider.

[rgaiacs]

Looks good to me.

[minrk]

Because we don't set strict channel priority, it is possible for a downgraded solve to pick from defaults in situations where packages are being downgraded, or version requirements are unsatisfiable on conda-forge. This should still be very unlikely.

This also removes unnecessary repodata requests for the defaults channel that's going unused and might be blocked by firewalls.

[rgaiacs]

Renato Alves mentioned in the German RSE list that

At the moment 3 channels are firewall blocked across all EMBL sites: defaults, main and r. All these channels are under the same terms of service.

@minrk can we update this PR to include all three channels? defaults, main and r.

[minrk]

@rgaiacs I'm not sure what you mean. We had 2 channels (conda-forge, defaults), now there is 1 (conda-forge). main and r are not in the available channels list in config.

[rgaiacs]

@minrk looks good. I need more coffee. :-D

[minrk]

Because this removes an unused repodata request for the defaults channel, this should speed up installs ever so slightly.