WIP: testing on windows and conda packages/ wheels for master #5604
Conversation
|
Not that I currently |
tools/appveyor_install.ps1
Outdated
There was a problem hiding this comment.
Just in terms of organization, we already have some Travis-specific tools in .travis.
I think I'd prefer to see this sort of structure:
integration
+- travis (existing content in .travis)
+- appveyor
+- conda
and leave tools for just developer tools as it is now.
There was a problem hiding this comment.
Can do, I just didn't want to add to much to the main dir...
There was a problem hiding this comment.
Agreed. I think we'd just be adding one new top-level directory (integration) under which all of this CI/build management stuff would live. Probably should vendor our .deb and .rpm specs there, too someday.
There was a problem hiding this comment.
I use "ci" which I found easier to identify than "integration" (It's also used be pandas)...
There was a problem hiding this comment.
didn't yet push the travis stuff to that dir...
|
I will remove |
|
Is there a flag on circleci that someone with admin rights needs to flip? |
|
On appveyor: someone with owner/admin rights on the github matplotlib org needs to login there and enable it. |
|
@tacaswell: Do you mean circleci or appveyor? I experimented with a bunch of these at one time, so I wouldn't be surprised if we have accounts a number of places already. @JanSchulz: I'll try to enable appveyor. |
|
I added matplotlib/matplotlib as a repo on appveyor. Not sure how to fire this off again, though. Maybe you need to push something to this branch. |
|
Sorry, meant appveyor, just having issues keeping them all straight 🐑 |
|
@mdboom Thanks! Currently I have a appveyor build my master branch. Not sure what it does with PRs... We'll see on my next push :-) Latest problem: on 2.7, 32bit: on 3.5, 64bit: |
|
Does anything in https://github.com/jbmohler/matplotlib-winbuild help? |
|
@tacaswell The normal wheel build works, I think it's something which is missing in the conda build environment... Right now I guess the include for MSVC? |
|
@mdboom: can you post a link to the project page on appveyor? Mine looks like https://ci.appveyor.com/project/JanSchulz/matplotlib I tried https://ci.appveyor.com/project/matplotlib/matplotlib, but that didn't work |
|
I seem to have attached it to my account by randomly pressing buttons... https://ci.appveyor.com/project/tacaswell/matplotlib |
I also did the same, I guess. It's set up for the |
|
Looks like appveyor is reporting back here now. Progress! |
|
Unfortunatly it's also reporting back on other prs i.e. #5591 |
|
Fun: 349762b introduced a depency on functools32 for py27, but conda has not yet such a package although such a package exists in their conda-recipe repo... Ok, so no 2.7 packages... |
|
I'll report the functools32 issue. |
|
Ok, I have no clue what this is: py35, 64bit: This seems to be reported in python upstream: https://bugs.python.org/msg248651 https://bugs.python.org/issue24872 |
|
Just in case it hasn't been said explicitly: thanks so much for taking this on, @JanSchulz. At a recent meetup at PyData NYC, it was made pretty clear that the percentage of Windows use in our developer pool is approaching zero while the percentage of Windows among our users is easily more than half and growing as scientific Python makes its way into corporate environments. So anything we can do to keep things working better on Windows is greatly appreciated. |
|
Btw, when this gets all cleared up and kinks ironed out, we should probably On Wed, Dec 2, 2015 at 2:28 PM, Michael Droettboom <notifications@github.com
|
|
@mdboom Ok, the functool32 addition in conda-recipe is a recent addition: conda-archive/conda-recipes#459 I really wonder how up-to-date conda-recipe is and how much magic is installed in anacondas autobuilder to let the matplotlib recipe produce the py35 packages of matplotlib :-/ |
|
FWIW, https://bugs.python.org/msg248651 and https://bugs.python.org/issue24872 are obsolete and do not apply to Python 3.5 final. |
|
@cgohlke thanks for the clarification! back to the drawing board for py35... :-/ But only after 2.7 and 3.4 are running :-) |
|
As far as I know Python 3.5 is build with visual studio 2015 and not visual studio 2010 so perhaps that is the reason? |
|
@tacaswell @mdboom One of you should probably remove the appveyoir integration: currently both of you run builds for each PR: github shows me the mdboom variant, but at some point I got the link to tacaswell. |
3.5 does not need a sdk, so don't set the variables in that case...
|
@mdboom I deleted mine |
I have no idea what is wrong with it and the easiest way would be to replace it with one which is known to work: https://github.com/pelson/Obvious-CI/blob/master/scripts/obvci_appveyor_python_build_env.cmd
|
Yay, appveyor and travis are green... |
|
@JanSchulz I am inclined to merge this now that the tests are passing so the rest of the PRs can report success on windows and iterate on the build products in a new PR. |
|
I'm all for it... I would add the rest of the todos to another issue/PR and get them fixed there... I've also build functools32 and matplotlib in my package_builder repo and the packages are currently uplaoding: https://anaconda.org/janschulz I will update the conda packaging for osx/linux from that, so one could build conda packags via |
WIP: testing on windows and conda packages/ wheels for master
|
👍 thanks! Should probably back-port this to 2.0.x ? @mdboom |
|
If someone wants to test it: https://anaconda.org/janschulz/matplotlib/files conda install -c https://conda.anaconda.org/janschulz matplotlib [These are packages form my package builder repo, so they are available in a conda repo (for osx+win+linux and not win-only in the appveyor artefact). On the other hand: no wheels...] |
There was a problem hiding this comment.
This is not necessary (and needs to be removed). Runtime determination of the version can be done with:
{% set data = load_setuptools() %}
package:
name: my_package
version: {{ data.get('version') }}
There was a problem hiding this comment.
Ui, first time I see that way to specify the version. I used the docs to get to that patch: http://conda.pydata.org/docs/building/meta-yaml.html#package-version
Why the "needs to be removed"?
There was a problem hiding this comment.
Why the "needs to be removed"?
I hope it didn't come across as rude - I just wanted to be clear that if we remove this form, we fix the problem you describe in the recipe whereby:
# Note also that our setup.py script, which is called by conda-build, writes
+ # a __conda_version__.txt file, so the version number on the binary package
+ # is set dynamically. This unfortunately mean that conda build --output
+ # doesn't really work.
```.
WIP: testing on windows and conda packages/ wheels for master
Remove setup.py tests and adapt docs to use tests.py conflicts in setup.py due to parts of #5604 being back-ported as well. Removed the windows bdist patch code to resolve.
This commit squashes 87c968b a30ec66 and cherry-picks them to the v1.5.x branch. These commits were merged to master as part of #5604 which was not backported en-mass. Original commit messages: Do not run Windows' file system convert tool On Windows, initialize the animation.convert_path setting from the Registry
Unsolved todos now in #5629
Current Todo:
See also the discussion at #5595
Closes: #5595
Closes: #5610 # test failures on windows
Closes: #5460 # PR which fixes a testfailure originally reported in #5446, merged into this PR
Closes: #5278 # namedTempfile on windows problem