{"action":"created","issue":{"url":"https://api.github.com/repos/conda/conda/issues/2323","repository_url":"https://api.github.com/repos/conda/conda","labels_url":"https://api.github.com/repos/conda/conda/issues/2323/labels{/name}","comments_url":"https://api.github.com/repos/conda/conda/issues/2323/comments","events_url":"https://api.github.com/repos/conda/conda/issues/2323/events","html_url":"https://github.com/conda/conda/pull/2323","id":145423674,"number":2323,"title":"Better handling of channel collisions. Discussion required.","user":{"login":"mcg1969","id":2797735,"avatar_url":"https://avatars.githubusercontent.com/u/2797735?v=3","gravatar_id":"","url":"https://api.github.com/users/mcg1969","html_url":"https://github.com/mcg1969","followers_url":"https://api.github.com/users/mcg1969/followers","following_url":"https://api.github.com/users/mcg1969/following{/other_user}","gists_url":"https://api.github.com/users/mcg1969/gists{/gist_id}","starred_url":"https://api.github.com/users/mcg1969/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mcg1969/subscriptions","organizations_url":"https://api.github.com/users/mcg1969/orgs","repos_url":"https://api.github.com/users/mcg1969/repos","events_url":"https://api.github.com/users/mcg1969/events{/privacy}","received_events_url":"https://api.github.com/users/mcg1969/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":39,"created_at":"2016-04-02T22:01:39Z","updated_at":"2016-04-06T20:25:45Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/conda/conda/pulls/2323","html_url":"https://github.com/conda/conda/pull/2323","diff_url":"https://github.com/conda/conda/pull/2323.diff","patch_url":"https://github.com/conda/conda/pull/2323.patch"},"body":"cc: @ukoethe @jakirkham \r\n\r\nThis is what I hope will be the first attempt to properly handle cases where packages with the same name are hosted in multiple channels. The current behavior does the following:\r\n\r\n1. When the package filenames are identical, the version found in a lower priority channel is dropped from consideration, even if that would have been the right choice for dependency reasons.\r\n2. Even when package filenames are distinct, they are prioritized as if they all came from the same channel. In particular, build numbers are assumed to imply consistent chronology across channels. But this clearly is not a correct assumption; build 5 in channel A could in fact be _older_ than build 10 in channel B.\r\n\r\nTo fix this we have done the following:\r\n\r\n- Assign a _channel priority number_ to each channel. For now, this number is assigned internally depending on the order of appearance in the channel list. The `defaults` channel actually consists of two different channels, but it is treated as one for the purposes of prioritization.\r\n\r\n- The solver's internal representation of the package list is currently a dictionary, where the key is the filename (`name-version-build.tar.bz2`). To solve problem 1, the key for any package outside of the default channel is prepended with the _canonical_ (short) channel name plus `::`. For example, using the default configuration settings, the channel `https://anaconda.org/conda-forge` translates to a prefix `conda-forge::` This eliminates problem 1 above; packages with the same filename, but in different channels, may now both be considered by the solver.\r\n\r\n- Packages in the default channel still use `filename` as the key; that is, with no `::` prefix. This aids transition and reduced the necessary modifications to the test suite. Note however that this means that package filenames must be unique across all of the channels aggregated into `defaults`. I think this is the right choice anyway.\r\n\r\n- A new configuration option `config.channel_priority` has been created. \r\n  - If `True`, the package sort order favors higher priority channels over version numbers. This ensures that if a user adds a new channel to their channel list, they can be sure that `conda` will pull from that channel as long as the dependency relationships allow it. If for some reason dependency requirements do *not* allow the packages from the favored channel to be installed, `conda` will drop down to the next priority channel.\r\n  - If `False`, the package sorting algorithm favors version numbers over channel priority. This means that the user wishes to obtain the latest version of a package, no matter what channel it comes from. Version number ties are broken by channel priority. This latter option *sounds* like the old behavior, but it is different in a very important respect: build numbers are *not* interleaved across channels.\r\n\r\nTo do:\r\n\r\n- We may want to add a third option that forces `conda` to consider *only* the highest priority channel where the package exists, and ignore completely any versions of the same package in lower priority channels.\r\n- I think we need a way to override the default channel priority on a per-package basis.\r\n- I think we need a way for a package to specify which channel its dependencies come from. Note that this needs to be done with great care lest it break older versions of `conda` (and even prevent them from upgrading to new versions). We can certainly allow a syntax like `channel::package` on the command line, but introducing those channels into the `depends` metadata would be problematic. This suggests the need to use new metadata fields to handle this.\r\n- A simple way to address the previous challenge for some packages is to have a boolean field called, say, `channel_lock`. If specified, all dependencies must come from the same (canonical) channel as the package itself. This seems like the right option for, say, `anaconda` itself.\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/conda/conda/issues/comments/206544651","html_url":"https://github.com/conda/conda/pull/2323#issuecomment-206544651","issue_url":"https://api.github.com/repos/conda/conda/issues/2323","id":206544651,"user":{"login":"kalefranz","id":1418419,"avatar_url":"https://avatars.githubusercontent.com/u/1418419?v=3","gravatar_id":"","url":"https://api.github.com/users/kalefranz","html_url":"https://github.com/kalefranz","followers_url":"https://api.github.com/users/kalefranz/followers","following_url":"https://api.github.com/users/kalefranz/following{/other_user}","gists_url":"https://api.github.com/users/kalefranz/gists{/gist_id}","starred_url":"https://api.github.com/users/kalefranz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kalefranz/subscriptions","organizations_url":"https://api.github.com/users/kalefranz/orgs","repos_url":"https://api.github.com/users/kalefranz/repos","events_url":"https://api.github.com/users/kalefranz/events{/privacy}","received_events_url":"https://api.github.com/users/kalefranz/received_events","type":"User","site_admin":false},"created_at":"2016-04-06T20:25:45Z","updated_at":"2016-04-06T20:25:45Z","body":"@mcg1969 A few question related to `channel::`...\r\n\r\n1. Are full urls handled easily and correctly?  I'd consider all of the following valid channels\r\n  * kalefranz\r\n  * conda.anaconda.org/kalefranz/label/dev\r\n  * https://conda.anaconda.org/kalefranz/\r\n  * s3://some-bucket/\r\n  * file:///home/kalefranz/conda/conda-bld\r\n  * /home/kalefranz/conda/conda-bld\r\n2. What happens if a noarch package has a completely equivalent channel priority and VersionOrder to an arch-specific package?"}}