I'm of mixed opinions about this. First impression: This may be easier on developers, but this could be a sturdy nail in the coffin of "Sage as a viable replacement to M*". Fragmenting Sage even further is going to make it harder to install, and harder to ensure any standards of * quality * performance * documentation * portability (give up now on Windows, if you haven't already)
On second thought: Matlab seems to make good money selling external packages, so apparently, people are willing to go through some extra effort to get the parts they need. If it was dead easy to install extra components from within the notebook, we could seriously slim down the required feature set. That way, we could *significantly improve the chances* of a successful Windows port. Most of us here would continue installing everything and the kitchen sink, but most users won't. So I guess I'm for it. I'm a little worried that this is going to fragment the developer base. But on the other hand, sage-combinat is a pretty awesome community, and in my opinion, a wild success. On Tue, Oct 26, 2010 at 6:44 PM, William Stein <wst...@gmail.com> wrote: > Hi, > > When I started Sage I viewed it as a distribution of a bunch of math > software, and Python as just the interpreter language I happen to use > at the time. I didn't even know if using Python as the language would > last. However, it's also possible to think of Sage as a Python > library. > > Anyway, it has occurred to me (a few times, and again recently) that > it would be possible to make much of the Sage distribution, without > Python of course, into a Python library. What I mean is the > following. You would have a big Python library called "sagemath", > say, and inside of that would be a huge HG repository. In that > repository, one would check in the source code for many of the > standard Sage spkg's... e.g., GAP, Pari, etc. When you type > > python setup.py install > > then GAP, Pari, etc., would all get built, controlled by some Python > scripts, then installed as package_data in the sagemath directory of > <your python>/site-packages/. > > From a technical perspective, I don't see any reason why this couldn't > be made to work. HG can handle this much data, and "python setup.py > install" can do anything. It does lead to a very different way of > looking at Sage though, and it could help untangle things in > interesting ways. > > (1) Have a Python library called "sagecore", which is just the most > important standard spkg's (e.g., Singular, PARI, etc.), perhaps > eventually built *only* as shared object libraries (no standalone > interpreters). > > (2) Have a Python library which is the current Sage library (we > already have this), and which can be installed assuming sagecore is > installed. > > (3) Have other Python libraries (like psage: > http://code.google.com/p/purplesage/source/browse/), which depend on > (2). Maybe a lot of the "sage-combinat" code could also be moved to > such a library, so they can escape the "combinat patch queue" madness. > Maybe many other research groups in algebraic topology, differential > geometry, special functions, etc., will start developing such > libraries... on their own, and share them with the community (but > without having to deal directly with the sage project until they want > to). > > To emphasize (3), when people want to write a lot of mathematics code > in some area, e.g., differential geometry, they would just make a new > library that depends on Sage (the library in (2)). We do the work > needed to make it easy for people to write code outside of the Sage > library, which depends on Sage. Especially writing Cython code like > this can be difficult and confusing, and we don't explain it all in > any Sage documentation. It actually took me quite a while to figure > out how to do it today (with psage). > > The core Sage library (2) above would continue to have a higher and > higher level of code review, tough referee process etc. However, the > development models for (3) would be up to the authors of those > libraries. > > The above is already how the ecosystem with Python > (http://pypi.python.org/pypi), Perl (http://www.cpan.org/), R, etc., > work. Fortunately, Python has reasonably good support already for > this. > > I think without a shift in this direction, Sage is going to be very > frustrating for people writing research oriented code. > > Fortunately, it's possible to do everything I'm describing above > without disturbing the mainline Sage project itself, at least for > now. > > -- William > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
