-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Specifying conda version used #2076
Comments
This could certainly be an option, we'd support this with our |
I would personally recommend just running |
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. |
Maybe we can use the keyword
but also accept the version number as
|
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:
Ultimately, 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" <[email protected]>
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
<#2076 (comment)>,
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 |
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
The text was updated successfully, but these errors were encountered: