Added HTTP Mirrors

[JohanMabille]

No description provided.

[AntoinePrv]

Shouldn't we rather take a specs::Channel?

[JohanMabille]

We could but that would require to store the channel in the SubdirData (which is where we get the channel_id), which means either duplicate it from the ChannelContext, or ensure the ChannelContext will live longer than the subdirs.
Besides, I'm not sure we need the entire channel information here, the channel_id is used to retrieve the mirrors stored in the Context; or we could refactor that to have the mirrors stored in the subdir directly (but again, this refactoring is beyond the scope of this PR).

[AntoinePrv]

The channel have value semantics so it does not need to be stored anywhere.
We may not need all the channel information but that make the API more clear as to what to expected and where to get it.

[JohanMabille]

The channel have value semantics so it does not need to be stored anywhere.

I think these are unrelated. Unless you want to resolve channels every time you need them, you have to store the channels somewhere once you have created them. And if f we want to avoid passing the Context and the ChannelContext everywhere, we should definitely create the channels once and for good at the "beginning".

[AntoinePrv]

Aren't channels already stored in the channel context for caching purposes? Plus they are not that expensive to resolve.
One of the point of the Channel refactor was to make them first class citizen, I feel this is going backwards, putting strings everywhere.

One difficulty though is that this is not even the URL to a channel but a subdir, for which we do not have information...

[JohanMabille]

Aren't channels already stored in the channel context for caching purposes? Plus they are not that expensive to resolve.

The issue is not they are expensive to resolve, but rather that you need the ChannelContext to resolve them (and then you need to pass it everywhere).

One of the point of the Channel refactor was to make them first class citizen, I feel this is going backwards, putting strings everywhere.

The string is only for the mapping channel <=> mirrors. We could actually change that for a "strong" typedef (ChannelId), but we definitely don't need the entire channel object here; and actually, a subdir is a "sub" channel, for a given platform,. If we store a channel in the subdir, we then may have a consistency issue with those in the ChannelContext; avoiding this consistency means either storing a reference (but then we need to ensure the values live longer than the references), or removing all the setters from the channels (which actually would be my preference).

So it's not going backward, but rather an intermediate state before we refactor the SubdirData and the cache in the ChannelContext.

[AntoinePrv]

Should we split that in two? Or even just hard code it where we need it?
I fear adding pypi code in Conda abstactions will just make it harder on the long run.

[JohanMabille]

Should we split that in two? Or even just hard code it where we need it?

I'm afraid that would lead to more bugs (because we'll have to split the code everywhere, and remember to add this specific use case each time we add a feature for regular arhcives. Also that would duplicate some code (since archives trigger the same behavior where they are identified).

The correct fix on the long run would be to have full abstrcations for pip packages (and later for other packages managers we may want to support), but that's beyond the scope of this PR.

[SylvainCorlay]