search

anaconda / anaconda-project

Tool for encapsulating, running, and reproducing data science projects
https://anaconda-project.readthedocs.io/en/latest/
Other
217 stars 88 forks source link

Project level .condarc does not seem to be respected #333

Open jlstevens opened 3 years ago

jlstevens commented 3 years ago

This issue is from feedback from a user in the 2021 SciPy tutorial (I could not reproduce myself but I did walk the user through the steps carefully to confirm the issue).

First channel_priority: strict in the user's .condarc meant the solve was failing. I was then hoping that a project level .condarc would take priority to ensure reproducibility but unfortunately this did not work.

I remember encountering this issue before but couldn't find any issue or PR referencing it. My expectation is that for full reproducibility you should simply supply a project level .condarc to ignore all other possible .condarc settings.

jbednar commented 3 years ago

That's pretty serious! An anaconda-project archive should be as self contained as practical, so that it can be reproducible. I'm confused about why that setting would have any effect at all, given that this was a fully locked project -- shouldn't that locking have pinned it to a particular package version from a particular channel already? I would have hoped that without even supplying a .condarc it would be independent of such settings in .condarc, even if it was e.g. respecting proxy settings so that it can access packages behind a firewall.

jlstevens commented 3 years ago

... given that this was a fully locked project -- shouldn't that locking have pinned it to a particular package version from a particular channel already

That is a very good point. Even with the lock this problem was reported.

AlbertDeFusco commented 3 years ago

This bug is plausible. Good idea to support a local condarc. I think I can reproduce the bug.

jbednar commented 3 years ago

Thanks! I'd say that respecting the lock would be the first and more important step, so that he condarc file doesn't matter much.

AlbertDeFusco commented 3 years ago

I suspect that the fix is to include the channel in the package name in the lock file. Something like this

- <channel>::<name>=<version>=<build>
jbednar commented 3 years ago

D'oh! I never actually look into the lock files because they are so long, so I assumed they already had the channel in there. Apparently not! Yes, then I can't think of any good reason they wouldn't have the channel, particularly since they include build numbers and thus can't really match anything from some other channel.