Making "stable" version be the latest feature release #103
Conversation
…e version. Now it’s set to 1.1, but if it works, we can update it easily to use 1.2 instead.
|
By the way, I just opened conda/conda#2777 because I believe there is an underlying conda bug. |
| @@ -9,6 +9,10 @@ conda config --add channels defaults | |||
|
|
|||
| shopt -s nocasematch | |||
|
|
|||
| LATEST_ASTROPY_STABLE=1.1 | |||
| LATEST_ASTROPY_LTS=1.0 | |||
| LATEST_NUMPY_STABLE=1.11 | |||
There was a problem hiding this comment.
Do we need the last two variables here?
There was a problem hiding this comment.
No, not yet. Depends whether we want to hack around the numpy issues ("stable" should never pick up 1.5 or 1.8), or can rely on that it will be fixed in conda soon?
There was a problem hiding this comment.
Also it can be a plan to rename these as "minimum stable" (e.g. 1.1 for astropy and 1.10 for numpy), to allow some flexibility and only upgrade with pip when something is messed up terribly.
There was a problem hiding this comment.
I don't think things will work well with Numpy, because if you update just numpy from 1.5 to 1.11, I think a lot of packages built on Numpy will fail. I really hope the conda command gets fixed soon.
There was a problem hiding this comment.
You're right with 1.5 vs latest stable, but we do the same with when
installing the development or the prerelease version.
On 20 June 2016 at 11:37, Thomas Robitaille notifications@github.com
wrote:
In travis/setup_dependencies_common.sh
#103 (comment):@@ -9,6 +9,10 @@ conda config --add channels defaults
shopt -s nocasematch
+LATEST_ASTROPY_STABLE=1.1
+LATEST_ASTROPY_LTS=1.0
+LATEST_NUMPY_STABLE=1.11I don't think things will work well with Numpy, because if you update just
numpy from 1.5 to 1.11, I think a lot of packages built on Numpy will fail.
I really hope the conda build gets fixed soon.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/astropy/ci-helpers/pull/103/files/5745166c2395eb9e6951fa79c872f01d6e8eefd3#r67668740,
or mute the thread
https://github.com/notifications/unsubscribe/AGeUwtayfJ00B0Cy8qCG8kkTThBZcPaMks5qNm1ugaJpZM4I5jvO
.
There was a problem hiding this comment.
Yes - I think it usually works ok because the ABI is less likely to change from say 1.11 to dev. But strictly speaking, dev/prerelease installations could break. But going from 1.5 to 1.11 is going to cause issues.
There was a problem hiding this comment.
though at the moment it may just pick up 1.5 for those, too :)
|
Do we need this for appveyor, too? I haven't seen any messed up builds there, but we are not really testing for old versions anyway. |
|
@bsipocz - so for Numpy, what about the solution of checking if it's stable and if so, changing to the latest stable version, but still using conda? In pseudo-code: For Astropy we can't really do that, because for e.g. Numpy 1.8 and Astropy 1.2 it might not be in conda. But the latest stable Numpy should be in conda. |
…this still not work for older python versions
|
Conda has a new option: Maybe we should be adding this to all conda commands? (in a separate PR) So I think the current behavior is a 'feature' not a 'bug', but we need to change that default. |
…versions are picked up from the astropy channels (that are ment to be complamentary to the main defaults channel)
| # version of astropy. | ||
|
|
||
| if [[ $ASTROPY_VERSION == stable ]]; then | ||
| $PIP_INSTALL --upgrade --no-deps astropy==$LATEST_ASTROPY_STABLE |
There was a problem hiding this comment.
So what about maybe checking the installed version and only doing this if it's not really the latest stable version?
There was a problem hiding this comment.
Indeed, originally meant to do it.
…s older than the latest stable version
bsipocz
changed the title
…anged back to 1.1 once the version is updatable in test.py (pending the windows condo build)
|
@bsipocz - we should make sure we add the no-channel-priority option on AppVeyor just in case. |
|
@astrofrog - Good point. |
|
@bsipocz - so it looks like there is a config item for this: I think it might be preferable to use that compared to adding the command-line flag? |
|
@astrofrog - Yep, I've just seen the comment on the conda issue. It turned out that my local conda where I checked for this was super old... |
|
@bsipocz - is there a way to list all available config options? |
|
My only way was to write in something invalid, then it lists the keys. Whether it is a complete list or not, I have no clue. |
…for linux and osx, but not yet for windows
|
🎉 Finally, this should fix "stuff"! |
|
Thanks @bsipocz! I've restarted some of the failing astropy-helpers PRs. |
This is to work around the recent conda issues when a very old astropy version was picked up when asked for "stable". We make sure that the installed version is from the latest feature release.
In most cases we don't need to force it to be the latest bugfix release, and if a package needs that bugfix they should explicitly state that version number in their travis file rather than use stable.
This is for #100 #98