-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow setting channels #24
Comments
All of this comes down to the fact that CondaPkg might find multiple CondaPkg.toml files (e.g. in your project plus some of its dependencies) and it needs to decide how to merge them. That, plus Conda only has two ways to specify channels: a list of channels to look in for all packages (via the
Ultimately, I think CondaPkg will change to use the The reason I don't use |
See #25. |
Whoa! I thought I knew a bit about conda, what with doing all sorts of conda-build fanciness, maintaining conda-forge packages, etc. But I had never come across the Thanks for explaining your reasoning. That all makes sense. |
As mentioned in JuliaPy/PythonCall.jl#115, it can be necessary to specify the channel from which a particular package should be installed. But
CondaPkg
went against my expectations in three ways that seems to make that impossible.PythonCall.jl
, it addsconda-forge
to the channel list, even when it hasn't been added in my ownCondaPkg.toml
(or~/.condarc
). This seems to be because it picks upPythonCall/CondaPkg.toml
, which has no channels listed, and therefore these lines add inconda-forge
. It seems like thatif
statement should come after thefor env
loop.--no-channel-priority
, which makes it impossible to — for example — ensure that thenumba
channel takes priority over theconda-forge
that was automatically added above. Any prioritization given inCondaPkg.toml
should probably just be preserved, with channels added by the dependencies given lower priority.channel
part made it into the production code. This doesn't seem like a high priority, of course, since conda itself doesn't support that inenvironments.yml
.Speaking of
environments.yml
, is there any reason you chose to use a new spec for CondaPkg? It looks likeCondaPkg.toml
contains exactly the same information, but in a different format. It would be very convenient to just allow re-use ofenvironments.yml
files.The text was updated successfully, but these errors were encountered: