On May 18, 9:29 am, Brian Granger <ellisonbg....@gmail.com> wrote:
> > Not right now. I'm sure Michael Abshoff would agree that we are way
> > too busy just dealing with Sage itself.
>
> OK, I am not surprised - Sage is an ambitious undertaking.
Well, world domination isn't something for weekend warriors ;)
> > However, note that there are two versions *right now* -- Sage and SPD
> > -- and that this is not in any way increasing my workload or
> > Michael's. It's for this reason that I'm not sure I fully agree with
> > your statement above that "From a development perspective, it makes no
> > sense to have two separate projects (Sage/SPD)."
>
> Yes, SPD really is functioning as a Sage version. I also agree with
> you that another true Sage version could create additional work for
> the Sage devs - even if folks like myself and Ondrej agreed to
> spearhead it.
I see two things that need to happen:
* branding of SPD, i.e. Sage would be one such thing, the other would
be "Ondrej's super delicious FE package" or whatever.
* -sdist to create a minimal SPD skeleton, i.e. prereq and sage-
scripts. sage-scripts needs the infrastructure to pull together
various spkgs and created "install" and "deps". For Sage at the moment
we wouldn't have to got that way since we manually maintain those
files, but with a little work this should be doable via a little shell
script {and/or python I assume since having python to create a new
custom SPD seems reasonable). Then we just take it from there and see
where this journey leads us.
I think SPD will go much further than Sage alone and has the potential
to expand the scientific python community substantially since having
something that just works locally custom build from sources on pretty
much any decent OS is something that should work rather well ;).
> But, if in the medium term (as Michael is hoping for), the Sage build
> system can be improved to the point where both Sage and SPD are using
> the same infrastructure, that would help a lot. We could then create
> SPD releases with whatever spkgs that we need without burdening the
> Sage devs.
Yep. The main hope here is that in a year if you are a (scientific)
upstream python project you just cannot affort not to offer a spkg ;)
> Cheers,
>
> Brian
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
