(Disclaimer: I haven't yet read this entire thread when writing my response.)
Chris -- who wrote abelfunctions -- is a Univ of Wash grad student I > know. I recently ran into him and he told me that he had spent years > writing this package as a standard Python package depending on sympy > (mainly) and not Sage. However, it was getting quite frustrating to > finish abelfunctions, due to him needing things that are in Sage (I > think things like interval arithmetic?). He didn't want to develop > his code in a way that depended on Sage, because he wanted it to be > more widely available, and he clearly didn't see the value in having > the code packaged as part of Sage for only a few small things. This > is a great example of how our centralized monolithic approach is > overall not the best for the community at large. > > I've cc'd Chris in case he wants to clarify this, since I might not > understand. > I remember discussions of this "modularized Sage" proposal way back when I was an undergraduate so I don't think it's anything new. In fact, hearing William talk about these issues back then is, in part, what prompted me to design my Sage package the way I did. That being said, I can only really comment on my own experience developing Abelfunctions (http://github.com/abelfunctions/ableufncitons). As William mentioned, I started writing Abelfunctions such that only depended on very common core Python packages. Anaconda is very popular in the applied mathematics community and many of the key scientific computing packages I needed (e.g. Numpy, Scipy, networkx) are included in Anaconda as well as in Sage. This design seemed like a good idea at the time since my code could reach as many people as possible. However, I slowly realized that Sympy's limitations in *efficiently* performing exact arithmetic with polynomial roots would prevent me from completing my software. After attempting to basically write my own version of QQbar in Sympy I made the very difficult decision, after four+ years of my Ph.D. writing Sympy workarounds, to completely rewrite my code "using Sage". I'm glad I did even though it added time to my Ph.D. --- a very small amount of time compared to the amount wasted trying to get Sympy to do what I wanted. So I am definitely glad that something like Sage is around to provide those open source tools I needed. I didn't pursue writing Abelfunctions into Sage or even making Abelfunctions an "optional" or "experimental" listed spkg for several reasons: 1. *It is still in very active development* --- My quick (read: several month) total rewrite of Abelfunctions to use Sage reintroduced bugs that I squashed in the Python version. This is somewhat evidenced in the GitHub issues page. Because I'm constantly fixing and adding things as I finish my thesis it seems bothersome to have to push a new spkg after every commit. (Sure, I can write a script to try and do that.) 2. *It is a niche product* --- The mathematical communities I work with know about Abelfunctions and they have spread the word of its existence to those who might be interested. That's great. But I never assumed that it should be a standard part of Sage. Sage already takes too much time to compile so why bloat it with something that <1% of Sage users would ever touch? (Though, my implementation of Puiseux series in Abelfunctions is now making it's way into the Sage codebase.) 3. *GitHub is my resume* --- Headhunters have seen that I write code. I doubt they scan trac.sagemath as much as they do GitHub. Being able to put my code up on GitHub has made it clearer to others and to myself what my contribution to the math community has been. Not that I'm against sharing in an open-source project but to have Abelfunctions Trac tickets buried in the mound of other Sage issues didn't seem like a clear way to get people to work on this small project at the time. Overall, developing Abelfunctions as an "external" Sage package has been pretty effective. I have some minor complaints, including the fact that the standard "$ sage setup.py install" doesn't seem to work on all platforms and trying to get TravisCI to download and install Sage before being able to test my code is a bit of a pain. If people who want to use it are having trouble finding it then it's my fault, not Sage's, since I suck at advertising myself. (Writing this post about my own code was difficult enough.) I think if enough people write packages this way we will see what works and what doesn't thus putting the whole "let's refactor Sage to make it modular" into a more concrete setting. -- Chris -- 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.
