Included channels

[jakirkham]

An important question we should discuss is what channels to include. Currently we include the conda-forge channel and the free channel from defaults. conda itself appears to include a few channels that it calls defaults, which include the free channel, the pro channel, and msys2 channel (on Windows).

Should we include all of these channels? Should we just include the conda-forge channel and allow users/ourselves to add the other ones later?

[loriab]

Given the progress on The List (conda-forge/staged-recipes/issues/1063), the existence of which I wasn't aware of originally, a pure conda-forge channel list seems well worth a try. Dropping free is straightforward in the upper role, which is where the packages in specs: are sourced from. But the lower role is which channels in the resulting Miniconda-like installation are considered to be in the "defaults" channel. So even adding conda-forge there as is now could throw off any build tools that expect defaults to come from Continuum. For best control, might want None in the lower role (not that I've checked that constructor allows that).

[jakirkham]

Sure, that makes sense. Thanks for pointing out the distinction.

FYI I updated the links in that comment as GitHub was failing to redirect them to the code (got an error page). Hope that is ok. Please feel free to change them if I messed them up further somehow.

[loriab]

Ah, thanks for the link updates. The lower role is actually conda_default_channels, so prepared a fix.

[jakirkham]

Was giving some more thought on this point of the lower role and how it is configured. One solution might be to allow us to name the channels in the lower role so that they don't break with expectations, but are still provided as defaults. A more detailed write up of this idea can be found in issue ( conda/constructor#42 ).

[loriab]

I just read your constructor issue, and I pretty much agree. The current conda_default_channels behavior is well suited to the distribution use-case (essentially a one-step Miniconda + conda env, with explicit per-package channels) where one wants to effectively set the .condarc but otherwise hide the complication of channels from the user.

I completely agree that having the conda list reflect the actual channel of origin is necessary to understand the status of an install and to debug. conda/constructor#24 should help considerably when it's ready. Admittedly my assessment of constructor's capabilities is frozen circa late-June (when I found a set of compatible conda, conda-build, and constructor versions and stuck with them), but I'd be content if the channel information that conda_default_channels sets up in .condarc displays as equivalent to anaconda/miniconda. I suppose I worry about too much aliasing obfuscating origins. I have limited experience and so haven't needed to conflate subchannels/labels under a single channel name, but I can well believe an organization such as conda-forge might find a case.