Conda has gone through a lot of changes of late. Namely the 4.0 release. Given the large overhaul of the solver, there have been a few recent bug fix releases. It would be nice for users to specify the conda version used if they cannot work with 4.x yet or to opt-in to 4.x if they need it.
cc @Korijn @agjohnson
This could certainly be an option, we'd support this with our readthedocs.yaml via http://github.com/rtfd/readthedocs-build
I would personally recommend just running conda update conda -y at the start of each build.
Some people use specific versions of conda in their CIs. I think it is reasonable for them to set the version here to match.
It also helps when a bug enters conda to be able to pick a lower version that does not have this issue until it is fixed.
I would personally recommend just running conda update conda -y at the start of each build.
Maybe we can use the keyword latest for this and so run
conda update conda -y
but also accept the version number as 4.3.21 and run:
conda install conda=4.3.21 -y
To be frank, conda changes so much and has seen so many instabilities, I would rather allow users to bring their own deploy scripts, rather than adding an option each time something needs to be changed. RTD will always be lagging behind. Just let your users handle it!
@Korijn my proposal receives the version from the user: a pinned one or latest.
I need a newer conda version - the current on rtd crashes. Is that possible with the current setup
@wkerzendorf That sounds like a different issue. Could you create a new issue for that, showing the logs?
I think updating conda releases at build time fixes a number of conda issues for now -- we're actually still on 4.2.x on the stable build images.
If anyone wanted to take on configurable conda versions, here are the changes required:
readthedocs/doc_builder/python_environment.py on this repositoryUltimately, does staying up to date with conda releases, alone, solve more problems? Do we really need to provide granular configuration of conda? My guess is no, most users would be better served by the latest version of conda. However, I say this without using conda for any repositories.
@agjohnson I would argue along the same lines that the vast majority of users are much better served using the latest conda version. This would also mean that if problems occur this will use the team from continuum io (a company with much more resources and money), rather than requiring input from the RTD team. Would it be possible to try this?
I think we are forcing conda to not upgrade automatically.
Why not just adding an option in the yaml altering this so the user can
tells the conda command to auto update when creating the environment?
So, RTD maintains just one version and experienced users can use the latest
on their own?
El 19 oct. 2017 11:41 a. m., "Wolfgang Kerzendorf" notifications@github.com
escribió:
@agjohnson https://github.com/agjohnson I would argue along the same
lines that the vast majority of users are much better served using the
latest conda version. This would also mean that if problems occur this will
be fixed by continuum io (a company with much more resources and money),
rather than requiring input from the RTD team. Would it be possible to try
this?—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rtfd/readthedocs.org/issues/2076#issuecomment-337966635,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAO7sNkssvF3AgdmJyE9InQQzhAkaK8Vks5st3u4gaJpZM4HzLnJ
.
FWIW I'm perfectly happy with your proposal @humitos.
Currently, we are alerted on any new releases to conda, we should be running the latest version on our build images -- or at least we'll be shamed by our CI into upgrading on a daily basis until we do upgrade :). Closing this as I don't see there being much use in a specific version of conda for end users. If anyone has a good reason for this, we can reopen this.
As a reference, I will leave this link here
https://github.com/rtfd/readthedocs-docker-images/blob/master/tests/test_dependencies.py
Most helpful comment
This could certainly be an option, we'd support this with our
readthedocs.yamlvia http://github.com/rtfd/readthedocs-build