-
-
Notifications
You must be signed in to change notification settings - Fork 18.1k
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
Use conda-env for CI environments #20767
Conversation
Limit coverage installs
That's pinned to numpy 1.10.4, which forces fastparquet 0.1.3, which is not compatible with thrift & pandas master.
Codecov Report
@@ Coverage Diff @@
## master #20767 +/- ##
==========================================
- Coverage 91.85% 91.81% -0.04%
==========================================
Files 153 153
Lines 49308 49310 +2
==========================================
- Hits 45290 45274 -16
- Misses 4018 4036 +18
Continue to review full report at Codecov.
|
Just one failure, on the OSX build. That's pinned to numpy 1.10.4, which forces fastparquet 0.1.3, which is not compatible with thrift 0.11. I could pin fastparquet & thrift to those versions, but I think fastparquet is adequately tested elsewhere, so I've removed it. |
conda-forge is only used for packages that are not found in the main
channel. The 3.5-osx env uses s3fs, moto, and feather which aren't in main.
…On Sat, Apr 21, 2018 at 4:58 PM, Jeff Reback ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In ci/travis-27.yaml
<#20767 (comment)>:
> @@ -0,0 +1,49 @@
+name: pandas
+channels:
can we have one of the main builds NOT use conda-forge (maybe the 3.5
one)? in the original we had *only* the 3.6 build using it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#20767 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQHIm1m0wI5okUh48J5wdN242UHGUIbks5tq6uFgaJpZM4Tdo8r>
.
|
I understand. my point is in the existing setup, we install from defaults ONLY for most packages. I am loath to give that up on at least 1 build. I would either go back to 2 steps on 1 or more builds, or remove these deps (e.g. you can install from pip instead these packages). |
I think you can completely remove the JOB= env variable as well here (or maybe rename ENV_FILE to JOB) |
also I don't think the issue number is correct here, #20720 ? |
I'd like to avoid installing moto from pip if possible. It brings in a lot of dependencies, which aren't managed by conda. This closes #20720. It looks like that was caused by the 2 / 3 stage installs, since we ended up with multiple versions of requests, boto, etc., in the same environment. Now we just have the one. I haven't seen any of the network failures on this branch. |
pip install cpplint | ||
fi | ||
|
||
if [ "$COVERAGE" ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where did coverage go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The coverage deps are run on the 3.6 build. travis-36.yaml
has the additional coverage deps.
ok I recently added some xfails for #20720, can you remove in this PR? |
Does the |
Small note: I personally liked the JOB tags to have a quick overview of the different build types. I know the ENV_FILE tag is similarly unique, but a bit less user friendly to read or to refer to ("check travis job ...") |
Not correctly unfortunately :( When I tried that, all the packages came from conda-forge. I suspect conda parses the deps for channels, and if found adds them to the start of the package list. Opened conda/conda#7202 for that. |
This reverts commit f70a6dc.
Reverted the |
I don't have a problem with the slightly longer ENV_FILE, maybe just rename this to JOB? |
Or maybe like before where the JOB tag is the variable part in the file name? |
By file name, do you mean the environment.yaml? Because if so, I think
that's the case.
I don't really care what we do here. In general, I like the idea of a small
tag that identifies the relevant bit for each build. Now that we aren't
using the `{.build,run,pip,sh}` files, we're free to put whatever we want
in `JOB`.
I removed the unused 3.5 files.
…On Mon, Apr 23, 2018 at 8:42 AM, Joris Van den Bossche < ***@***.***> wrote:
Or maybe like before where the JOB tag is the variable part in the file
name?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#20767 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQHIqGuDliwjnIcLB8pYPZytFQzt3dfks5trdpfgaJpZM4Tdo8r>
.
|
Yes, that is what I meant. All environment files for travis are like |
This reverts commit cd50adb.
lgtm merge away |
FYI, the I tried it out with conda-canary and things seemed to work fine. |
Closes #20720
The old setup where things were installed in multiple places resulted in some strange environments, with multiple copies of the same package in
site-packages
.This attempts to reduce the environment definition to a single file per CI job, and the environment installation to 3 steps
Travis only for now. Will move over the appveyor / circle ones too.