On Fri, Apr 8, 2016 at 1:00 AM, Volker Braun <vbraun.n...@gmail.com> wrote: > 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.
(Volker, I really hate to disagree with you, since I respect you *very* highly.) However, this is where you are wrong. Just because it is technically possible to do something and documented how to do so online, doesn't mean there is nothing to do on the sage side. Software, Sage, etc. is all about people, what they endorse, what examples they set, etc. It's a leadership thing. The very thing that makes you say "there is nothing to do" is what tells me "there is a lot to do". > > >>> >>> 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. I continue to disagree. > Much of the memory usage of the current docbuild is the huge intersphinx > data, and no amount of modularization would make that smaller. I disagree. If the elliptic curves docs aren't in Sage at all (say), then it certainly isn't going to make that stuff larger. > 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. And for 99.99% of sage users who don't know an elliptic curve from an "elliptical curve" there is no gain by having the elliptic curves in the same daunting reference manual as plotting functions. > > > -- > 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.
