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). William On Sun, Jun 5, 2016 at 3:59 PM, Nils Bruin <nbr...@sfu.ca> wrote: > If one is experimenting with mathematical computations, one would usually > start interactively, with a jupyter worksheet, an emacs buffer, or just a > terminal with cut&paste. The sage environment is pretty good for that. Once > the project gets larger, one would start to put code into files that are > loaded and possibly even "import"ed. For python code, that is easy: you can > just put the code wherever it is convenient and as long as you make sure > python looks there for packages (e.g. the current directory), an "import" > will do what it is supposed to. > > If one uses cython code to make extension modules, things seem to get a > little more complicated, though. For interactive usage the %cython and > cython("...") methods work nicely to incorporate code into a > worksheet/interactive session, but it's not so clear how to spin that off > into a separate module without putting it in the actual sage tree (which > would require write permission on that sage tree!) > > Do we have ways to support a workflow for projects that are at a stage that > is in-between "a big worksheet" and "incorporating in the sage library"? > > The problem arose specifically when I was looking at > https://github.com/abelfunctions/abelfunctions which packages itself as an > spkg. Obviously, I didn't want to install this (when trying it out!) in a > system-wide sage, but I also didn't want to force the student who needed to > look at it to build a private sage version just to try out a package. > > I was thinking about what alternative we have to "spkg" that does work for > users privately. Python packages can be installed specifically for a user, > while still relying on the system-wide python for general support. Is there > an obvious way to support this for cython modules too? If someone knows of a > good tutorial for that kind of thing, I would be very interested! > > -- > 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. -- William (http://wstein.org) -- 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.
