Repository navigation
No Windows wheel available on PyPI for new version of matplotlib (1.5.2) #6966
Description
Hello,
There is no Windows wheel for the latest version of matplotlib on PyPI (1.5.2), they exist for 1.5.1 though.
This situation forces every Windows user of matplotlib to build the library and download all the requirements necessary for this task.
Can you (or someone) provide Windows wheels for 1.5.2 on PyPI?
Thank you and have a good day! :)
Activity
tacaswell commentedon Aug 23, 2016
attn @matthew-brett
matthew-brett commentedon Aug 23, 2016
Oh - dear - I'm not a Windows expert. Who was building the Windows wheels before?
tacaswell commentedon Aug 23, 2016
Sorry, I misunderstood and thought you were taking care of all of the wheels. @cgohlke usually builds the wheels.
matthew-brett commentedon Aug 23, 2016
@cgohlke - can we set up Appveyor to do this? Do you have a good recipe to share?
tacaswell commentedon Aug 23, 2016
1.5.3 is stalled on me finding time to do the backports.
The wheels have now been uploaded so closing this issue.
jankatins commentedon Aug 24, 2016
It should be possible to upload wheels directly from appveyor (https://www.appveyor.com/docs/deployment/github/ -> push on tags) using the latest version of twine (which includes changes to specify the repo on the commandline and user+pass in env variables)
So one could install twine into the conda env (following conda-forge/staged-recipes#1354), add the env variables (mdboom must do the encryption of the TWINE_PASSWORD variable on his appveyor account) and then add the
deploy:config to the appveyor script.matthew-brett commentedon Aug 24, 2016
I personally haven't done this in the past because the release manager may have to wait for all the builds to pass before uploading, in case they have to fix something. So I like the manual step of uploading to give me some pause space before pulling the trigger.
jankatins commentedon Aug 24, 2016
re upload on tag vs upload manually: that more or less depends on whether it is allowed to force push tags into the repo or not: if you are not allowed to force push then uploading everything is fine (more or less: there could be a small time when the broken release is on the servers) because you would anyway have to cut a new release for the hotfix version.
Anyway: a conda-forge feedstock style repo would also be a possibility (unfortunately, there isn't yet a script which does for wheels what conda-smithy does for conda-forge feedstocks: build CI scripts, register the repo at the CI services, encode tokens for each CI service.
matthew-brett commentedon Aug 24, 2016
For pypi, you aren't allowed to upload a file with the same name as one previously uploaded - so you may find yourself having to make a new release.
jankatins commentedon Aug 24, 2016
@matthew-brett exactly, but the same happens in the repo (assuming a "no force push" policy and reproducible builds -> Every difference in the wheel build must be done by a difference in the repo).