Skip to content
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

Put conda-forge over defaults in windows tests #5228

Merged
merged 3 commits into from Aug 6, 2019

Conversation

@jcrist
Copy link
Member

commented Aug 5, 2019

Our windows tests are currently failing, likely due to a difference in
environment (numba 0.45.0 is being used from defaults in appveyor, numba
0.45.1 is being used from conda-forge on travis). We update our
environment.yml to specify using conda-forge over defaults when
possible.

Put conda-forge over defaults in windows tests
Our windows tests are currently failing, likely due to a difference in
environment (numba 0.45.0 is being used from defaults in appveyor, numba
0.45.1 is being used from conda-forge on travis). We update our
environment.yml to specify using conda-forge over defaults when
possible.
@jcrist jcrist referenced this pull request Aug 5, 2019
2 of 2 tasks complete
@jcrist

This comment has been minimized.

Copy link
Member Author

commented Aug 5, 2019

Hmmm, this may also be due to pydata/sparse#257. Will wait for appveyor before looking further.

@jrbourbeau
Copy link
Member

left a comment

Thanks for handling this @jcrist! Left a couple of small comments

continuous_integration/appveyor/environment.yaml Outdated Show resolved Hide resolved
@@ -1,10 +1,11 @@
name: testenv
channels:
- conda-forge
- defaults

This comment has been minimized.

Copy link
@jrbourbeau

jrbourbeau Aug 5, 2019

Member

Do we need the default channel, or does conda-forge still suffice?

This comment has been minimized.

Copy link
@jakirkham

jakirkham Aug 6, 2019

Member

This looks correct to me. Dropping it would mean we don't use defaults at all, which is probably not what we want.

This comment has been minimized.

Copy link
@jrbourbeau

jrbourbeau Aug 6, 2019

Member

Is there a reason to use defaults if all the packages we want to install are in conda-forge?

This comment has been minimized.

Copy link
@jcrist

jcrist Aug 6, 2019

Author Member

Dropping it would mean we don't use defaults at all, which is probably not what we want.

Actually, IIUC this change was worthless except for explicitly orderining conda-forge and defaults - we'd have to add nodefaults to the channel list to disable defaults entirely (otherwise its implicitly there): https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html

The real fix here was to pin numpy, but I'm reluctant to make another commit since this PR works as is and this change is harmless.

This comment has been minimized.

Copy link
@jrbourbeau

jrbourbeau Aug 6, 2019

Member

If so, we may consider adding defaults to our other CI environments (doesn't have to be in this PR)

This comment has been minimized.

Copy link
@jrbourbeau

jrbourbeau Aug 6, 2019

Member

I'm reluctant to make another commit since this PR works as is and this change is harmless

Totally fine by me. I was just curious if I was missing something about how specifying channels works with conda

@jakirkham

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

Some minor comments. Otherwise LGTM. 🙂

Update continuous_integration/appveyor/environment.yaml
Co-Authored-By: jakirkham <jakirkham@gmail.com>

@jcrist jcrist merged commit e8741ae into dask:master Aug 6, 2019

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jcrist jcrist deleted the jcrist:use-conda-forge-by-default branch Aug 6, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.