[Cython] [cython-users] Re: Cython 0.23.5 released

Nathaniel Smith njs at vorpus.org
Thu Mar 31 15:23:56 EDT 2016


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 at 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 at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20160331/c7e263bf/attachment.html>


More information about the cython-devel mailing list