Re: [Cython] [cython-users] Re: Cython 0.23.5 released
On Wed, Mar 30, 2016 at 2:35 PM, Forest Gregg <fgregg@gmail.com> wrote:
Thanks!
Are there also plans to post Windows wheels for cython 0.23.5 to pypi like there was for 0.23.4?
I did that earlier today, using an Appveyor build system : https://github.com/MacPython/cython-wheels/blob/master/appveyor.yml https://ci.appveyor.com/project/matthew-brett/cython-wheels http://win-wheels.scikit-image.org/ Do they work for you? Best, Matthew
On Mar 31, 2016, at 00:50, Matthew Brett <matthew.brett@gmail.com> wrote:
On Wed, Mar 30, 2016 at 2:35 PM, Forest Gregg <fgregg@gmail.com> wrote:
Thanks!
Are there also plans to post Windows wheels for cython 0.23.5 to pypi like there was for 0.23.4?
I did that earlier today, using an Appveyor build system :
https://github.com/MacPython/cython-wheels/blob/master/appveyor.yml https://ci.appveyor.com/project/matthew-brett/cython-wheels http://win-wheels.scikit-image.org/
Do they work for you?
They work for building gevent on Appveyor. The cython binary wheels cut gevent's total build time by more than half (they save almost 10 minutes). Thanks! Jason
On Thursday, 31 March 2016 00:50:57 UTC-5, Matthew Brett wrote:
Thanks!
Are there also plans to post Windows wheels for cython 0.23.5 to pypi
On Wed, Mar 30, 2016 at 2:35 PM, Forest Gregg <fgr...@gmail.com <javascript:>> wrote: like
there was for 0.23.4?
I did that earlier today, using an Appveyor build system :
https://github.com/MacPython/cython-wheels/blob/master/appveyor.yml https://ci.appveyor.com/project/matthew-brett/cython-wheels http://win-wheels.scikit-image.org/
Do they work for you?
They work for building gevent on Appveyor. The cython binary wheels cut gevent's total build time by more than half (they save almost 10 minutes). Thanks! Jason
Jason Madden schrieb am 31.03.2016 um 15:13:
On Thursday, 31 March 2016 00:50:57 UTC-5, Matthew Brett wrote:
Thanks!
Are there also plans to post Windows wheels for cython 0.23.5 to pypi
On Wed, Mar 30, 2016 at 2:35 PM, Forest Gregg <fgr...@gmail.com <javascript:>> wrote: like
there was for 0.23.4?
I did that earlier today, using an Appveyor build system :
https://github.com/MacPython/cython-wheels/blob/master/appveyor.yml https://ci.appveyor.com/project/matthew-brett/cython-wheels http://win-wheels.scikit-image.org/
Do they work for you?
They work for building gevent on Appveyor. The cython binary wheels cut gevent's total build time by more than half (they save almost 10 minutes).
That makes me wonder if we shouldn't just provide pure Python wheels of Cython, i.e. without compiling any binary extensions in them. For one-time installs, it would only be marginally slower than with a compiled Cython, but it would work on all platforms with all Python versions. I guess the drawback would be that it would be more hassle for people who really want to install Cython permanently for themselves... Is there a way to tag a wheel somehow as "special"? I doubt that Nick&friends thought about the special Cython installation use case when designing the format... Stefan
On Mar 31, 2016 6:40 AM, "Stefan Behnel" <stefan_ml@behnel.de> wrote:
Jason Madden schrieb am 31.03.2016 um 15:13:
On Thursday, 31 March 2016 00:50:57 UTC-5, Matthew Brett wrote:
Thanks!
Are there also plans to post Windows wheels for cython 0.23.5 to pypi
On Wed, Mar 30, 2016 at 2:35 PM, Forest Gregg <fgr...@gmail.com <javascript:>> wrote: like
there was for 0.23.4?
I did that earlier today, using an Appveyor build system :
https://github.com/MacPython/cython-wheels/blob/master/appveyor.yml https://ci.appveyor.com/project/matthew-brett/cython-wheels http://win-wheels.scikit-image.org/
Do they work for you?
They work for building gevent on Appveyor. The cython binary wheels cut gevent's total build time by more than half (they save almost 10
minutes).
That makes me wonder if we shouldn't just provide pure Python wheels of Cython, i.e. without compiling any binary extensions in them. For one-time installs, it would only be marginally slower than with a compiled Cython, but it would work on all platforms with all Python versions.
I guess the drawback would be that it would be more hassle for people who really want to install Cython permanently for themselves...
Is there a way to tag a wheel somehow as "special"? I doubt that Nick&friends thought about the special Cython installation use case when designing the format...
The general case is "library with optional native acceleration". I think one thing is that if there's both a generic and a specific wheel then pip will prefer the specific one? So an arch-specific wheel will get higher priority than a py2.py3-none-any wheel. Of course this only works if both are available -- it's more of a fallback thing. -n
Nathaniel Smith schrieb am 31.03.2016 um 17:42:
On Mar 31, 2016 6:40 AM, "Stefan Behnel" wrote:
That makes me wonder if we shouldn't just provide pure Python wheels of Cython, i.e. without compiling any binary extensions in them. For one-time installs, it would only be marginally slower than with a compiled Cython, but it would work on all platforms with all Python versions.
I guess the drawback would be that it would be more hassle for people who really want to install Cython permanently for themselves...
Is there a way to tag a wheel somehow as "special"? I doubt that Nick&friends thought about the special Cython installation use case when designing the format...
The general case is "library with optional native acceleration". I think one thing is that if there's both a generic and a specific wheel then pip will prefer the specific one? So an arch-specific wheel will get higher priority than a py2.py3-none-any wheel. Of course this only works if both are available -- it's more of a fallback thing.
We could provide a separate release version for the wheel, e.g. 0.24 for normal sdist and binary builds and 0.24py for the unaccelerated pure Python wheel. People could then "pip install Cython==0.24py" on their CI servers and get a fast wheel installation. The wheel is really easy to build: pip install wheel python setup.py bdist_wheel --universal --no-cython-compile This quickly creates a file dist/Cython-0.24b0-py2.py3-none-any.whl Py3.2 wouldn't be supported, but that's it. Since Cython shouldn't normally show up in any requirements.txt files itself, and thus would usually be installed separately in CI builds, this scheme should be easy to apply for users. Using different versions is better than having different package names because the later would quickly lead to confusion when both packages get installed by accident and try to unpack the same files. We need to take care that PyPI's version sorting doesn't get confused by this, though. "pip install Cython" should still install the latest *accelerated* version. Does anyone know if the trove classifier Development Status :: 7 - Inactive has any effect on pip? Or should we mark the wheel package as "3 - Alpha" release? That should prevent pip from installing it by default (IIRC). Stefan
Pip ignores trove classifiers entirely. You could overload PEP 440 prerelease versions, which pip ignores by default, but I'm not sure I'd advise it, since those are rather useful for distributing prereleases :-). I think I missed something in the initial motivation here: if there's a precompiled binary wheel available for some platform, then that's what CI servers should use, right? So the goal here is to provide some convenient way for folks on unusual platforms without wheels -- like fbsd or arm Linux -- to get the behavior that "pip install Cython" does the lengthy build-from-source thing, but on CI servers they can instead run "pip install [something]" to get a quick install? And what's wrong with the current "pip install Cython --install-option="--no-cython-compile"? On Mar 31, 2016 11:29 AM, "Stefan Behnel" <stefan_ml@behnel.de> wrote:
Nathaniel Smith schrieb am 31.03.2016 um 17:42:
On Mar 31, 2016 6:40 AM, "Stefan Behnel" wrote:
That makes me wonder if we shouldn't just provide pure Python wheels of Cython, i.e. without compiling any binary extensions in them. For one-time installs, it would only be marginally slower than with a compiled Cython, but it would work on all platforms with all Python versions.
I guess the drawback would be that it would be more hassle for people who really want to install Cython permanently for themselves...
Is there a way to tag a wheel somehow as "special"? I doubt that Nick&friends thought about the special Cython installation use case when designing the format...
The general case is "library with optional native acceleration". I think one thing is that if there's both a generic and a specific wheel then pip will prefer the specific one? So an arch-specific wheel will get higher priority than a py2.py3-none-any wheel. Of course this only works if both are available -- it's more of a fallback thing.
We could provide a separate release version for the wheel, e.g. 0.24 for normal sdist and binary builds and 0.24py for the unaccelerated pure Python wheel. People could then "pip install Cython==0.24py" on their CI servers and get a fast wheel installation.
The wheel is really easy to build:
pip install wheel python setup.py bdist_wheel --universal --no-cython-compile
This quickly creates a file
dist/Cython-0.24b0-py2.py3-none-any.whl
Py3.2 wouldn't be supported, but that's it.
Since Cython shouldn't normally show up in any requirements.txt files itself, and thus would usually be installed separately in CI builds, this scheme should be easy to apply for users.
Using different versions is better than having different package names because the later would quickly lead to confusion when both packages get installed by accident and try to unpack the same files. We need to take care that PyPI's version sorting doesn't get confused by this, though. "pip install Cython" should still install the latest *accelerated* version.
Does anyone know if the trove classifier
Development Status :: 7 - Inactive
has any effect on pip? Or should we mark the wheel package as "3 - Alpha" release? That should prevent pip from installing it by default (IIRC).
Stefan
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
participants (4)
-
Jason Madden -
Matthew Brett -
Nathaniel Smith -
Stefan Behnel