On Friday, April 8, 2016 at 2:36:23 AM UTC+2, William wrote: > > Whats wrong with the obvious solution: make it a Python package (basically >> add setup.py) and then "sage -pip install >> https://github.com/vbraun/awesomepackage.git";. Clearly we could have >> more documentation for how to write the setup.py or some package directory >> service. But really it is already a one-liner. >> > > That is exactly what I'm proposing >
But then there is nothing to do on the Sage side, this already works and is totally standard. Documentation for how to package your own Python code can easily be found online. > Yes but cython and cysignals don't do anything for math directly, they are >> pure dependencies. By contrast, lets say we break out all elliptic curve >> stuff into a separate package. Just like with cysignals, this will remove >> all elliptic curve documentation from the Sage reference manual. Still a >> win-win? >> > 1. Not necessarily true. > It is if you want to have a uniform document with cross references working. Much of the memory usage of the current docbuild is the huge intersphinx data, and no amount of modularization would make that smaller. That is not to say that docbuilding can't be improved, but certainly not by spreading out the documentation sources. > 2. Is it so bad that the Cython docs aren't in the sage reference manual? > As I said before, cython and cysignals don't do anything for math directly so they are a special case. In fact, they shouldn't be in the main Sage docs even if they were part of Sage. -- 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.
