Fix Python versions used in CI environments #5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jakirkham
force-pushed
the
fix_ci_activate
branch
from
030a84f
to
8adfc69
Compare
This was working around an old issue with `openssl` in defaults where a post-link script that they had misbehaved when upgrading to packages in conda-forge. However this was long since fixed when Anaconda rebuilt with conda-forge packages, which did not have this script. So just drop the workaround.
jakirkham
force-pushed
the
fix_ci_activate
branch
4 times, most recently
from
5ecdf60
to
9821989
Compare
It seems that `conda env update` is overriding the match specification from the previous `python` install command. To fix this, we create the environment empty and pin the `python` version in the `pinned` file. This should be respected by `conda env update`.
jakirkham
force-pushed
the
fix_ci_activate
branch
2 times, most recently
from
414a91c
to
00df77b
Compare
Seems the current version of dependencies do not exist as `conda` packages in either `defaults` or `conda-forge`. So downgrade a little bit to get a version of `wheel` that works across Python versions.
jakirkham
changed the title
When it comes to setting the Python version for each environment use the `PYVER` environment variable to separate this from the Miniconda version and make the CI configurations more similar. Will allow us to update Miniconda independently of the Python version being tested.
Go ahead and use Miniconda with Python 3.7 for the Python 2.7 use case. After all there is no need to match Miniconda version to Python version being tested.
Simplify the environment variables in the AppVeyor configuration file by pulling out common ones from the matrix.
On AppVeyor, we are seeing issues with Miniconda's Python version being used instead of the one we are trying to pin. So try to drop quotes from the filename to see if it helps.
Seems these quotes are ending up in the `pinned` file, which may be causing them to be parsed in a weird way. Surprisingly the quotes don't result in any errors being thrown. In any event, hopefully this results in something digestible by Conda.
This space seems to be included in the content written into `pinned`. So drop the space so that it is not included in `pinned`.
This has served its purpose. So drop it to avoid cluttering the configuration file and logs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For some reason Travis CI builds were all using Python 3.7 instead of the specified Python version. This may be a change in how Conda solves these cases. So here we create an empty environment, activate it, and pin the Python version in that environment. That way updating it with the environment file afterwards has to keep the same Python version. Clean out the old
opensslhack and use the new environment activation process while we are at it. Also fix the dependencies to versions that are available on Python 2.7 and 3.5-3.7.