On 10/12/07, Mike Hansen <[EMAIL PROTECTED]> wrote:
> I've been thinking a bit about third-party packages for SAGE primarily
> because I have some software that I'd like to release, but it is too
> specialized for inclusion into the main branch. I think that when
> SAGE gets more popular, this will become more of an issues. Some of
> the requirements I can envision are the following:
>
> -- easy to install (spkgs should be fine for this)
> -- easy to load from within sage ( from sage.third_party.foo import * )
> -- handles upgrades nicely ( either they will not be overwritten
> during upgrades or they will automatically be re-pulled from somewhere
> and installed again with the new version)
> -- ...
>
> What are people's thoughts on this?
My first thought about this is that this should already be a very well
solved problem *modulo a little infrastructure* because Python itself
has excellent support for third party packages. I.e., if one has
a third party package with a name such as, oh let's say, "numpy",
then why should it be
from sage.third_party.numpy import *
when it should be
from numpy import *?
I.e., Python already does third party packages well, and Sage gets
that for free.
What I think Python probably doesn't do is organize a big list of
packages *that depend on Sage with descriptions, automatic testing,
automatic upgrades, etc.
I think ideally third-party packages for Sage should augment Python's support
for third party packages as follows:
(1) they should be spkg's, so the install possibilities are more flexible.
(2) they *must* have a clear protocol for being automatically tested,
(3) they need to be centrally hosted on sagemath.org (and mirror sites).
In particular, I think the single most *critical* feature is that every spkg
has to have a file spkg-check, so that the sagemath.org package maintainer
(maybe me?) can type one command and have all the spkg's installed
and their test suites run, and that this happen on a regular basis.
Also, I want to encourage Sage code to not be in separate packages
still, since Sage's functional range still isn't nearly big enough. By keeping
everything together, we make sage out of the box much more powerful,
and we should push that quite hard. Also, I think the quality of code
that goes into standard will likely be higher than third-party packages,
and better maintained, etc., so it's best for people to put in the extra
work to get code in their. That said, I of course understand that it would
be good ot have some third-party packages, e.g., a collection of .sage files
or some sage worksheets for calculus or whatever else, could all make
sense as third party packages.
-- William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
