On Mon, Jun 6, 2016 at 5:25 AM, William Stein <wst...@gmail.com> wrote: > We had tons of discussion on sage-devel about exactly this topic > recently. One thing is that Chris made > > https://github.com/cswiercz/sage_packages > > but that seems to have gone nowhere. > > I think that **all** development of Sage should be done using standard > Python packaging. Of course Cython is very well supported using > setuptools -- that's how the whole rest of the scientific computing > community, outside of Sage, normally works on code and uses Cython. I > would refer you to cython.org, but it's gone, along with the reset of > the UW infrastructure (see previous message).
This strays a little off topic, but one thing I will say is that the current documentation / advice that the Cython documentation gives regarding packaging isn't very good advice IMO. This is a nit I've been meaning to pick for a while and maybe I'll start a separate thread about it over at the Cython mailing list. The current docs tell you basically how to do it. Import cythonize(), call it on your list of Extension objects, boom done. But no, that's not right. Because what it doesn't explain (and that most people, especially new to Python packaging, don't understand) is that this breaks setup.py. I don't blame them for not understanding this because this is not well documented and is confusing, despite a handful of valiant efforts to improve the situation (many of which are ongoing and making great strides). Anyways I'll get to the point: The setup.py script provides an interface that is supposed to have certain (poorly documented) invariants. It is all too easy to break those invariants--this is due to poor design from the ground up. But I'm not going to argue about that--right now we're stuck with the system we have. To give an example, calling $ ./setup.py --name is supposed to print the distribution name to stdout. That's it; it should do nothing. It certainly shouldn't print anything else (and if it must, it should be to stderr). Likewise with `./setup.py --version`. These are trivial and not too important (in most cases) examples. But they are simple ones that illustrate the point: Your setup.py shouldn't be calling cythonize() every time you run `./setup.py`. It makes it slower, and can break things unexpectedly (especially to software like pip that consumes setup.py). In fact, you can't assume that Cython is even installed when calling setup.py, and the Cython docs don't really point that out. Now one thing the distutils/setuptools API does give you is the ability to override and write your own commands. In fact Cython used to advertise a CythonBuildExt command (i forget of that's exactly the name) that overrides the default build_ext command to also compile Cython modules as needed. It used to even be that setuptools would automatically replace its default build_ext with Cython's (and Pyrex's before that). I'm actually not up to date on whether that's still the case or not, but if it is it's a good reason to setuptools*--you don't even need to manually call cythonize. It will do it automatically when it's appropriate to (i.e. calling `./setup.py build_ext). That said, you still need to have a fallback for when Cython is missing. That's something that's sadly not provided. It would be better if setuptools detected Cython modules in your Extensions list and provided an error that they can't be compiled without Cython. Instead I usually find myself reimplementing this repeatedly (if I'm not using astropy_helpers). Maybe that's something I should propose to setuptools. Erik * I just checked the source of setuptools and it looks like it still does this. So if you use setuptools there's no reason to even follow the advice of calling cythonize() manually in the setup.py. My caveat about there being no automatic fallback still applies though. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
