>> > One package (Pysam) that I use a lot relies on Cython, and requires >> > users to install Cython before they can install Pysam itself. With Cython, >> > is that always the case? Will all users need to install Cython? Or is it >> > sufficient if only matplotlib developers install Cython? >> >> You can set things up so that end-users don't have to install cython. >> You just convert the .pyx files to regular .c files before >> distributing your package. Numpy itself uses cython, but end-users >> don't notice or care. (It's something more of a hassle for developers >> to do things this way, and cython is very easy to install, so I don't >> know if it's worth it. But it's certainly possible.) >> > > Since when has numpy used Cython? I specifically remember a rather involved > discussion thread on numpy-discussion about the pros-and-cons of including > cython. Now, SciPy on the other hand, does utilize Cython in some spots > IIRC, but does it in a way that it isn't even required for the developers to > have cython installed to build from source.
You just ship the c/c++ code for the developpers as well as for the end users. This is what we do with scikit-learn. It requires the developpers to make sure to compile the cython code, and commit both files. It is also quite annoying for reviews to have the generated c++ code, so the cython code needs to be compile after the reviews. The reason the scikit's developpers chose to use cython instead of something else is to decrease the maintenance burden: more contributors understand cython code than c/c++ code (or more precisely, understand c++ code written by someone else). Hence, this increases the bus number. > I would not be against such an approach. Much of the C/C++ stuff is rarely > touched. If we have some source cython that is used to generate C/C++ > source code that is packaged in the same way as the current code is, I would > have no problem with that. Given that matplotlib is such a fundamental tool > in the ecosystem, I want to make sure that the decisions we make are ones > that improves our packaging situation. > > Cheers! > Ben Root > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > INSIGHTS What's next for parallel hardware, programming and related areas? > Interviews and blogs by thought leaders keep you ahead of the curve. > http://goparallel.sourceforge.net > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
