On Wed, Oct 14, 2009 at 12:56 PM, Ralf Hemmecke <r...@hemmecke.de> wrote: > >>> Sage *is* different than other programs, since even in the binary >>> release it comes with .hg repositories (under devel and local/bin) and >>> lets users actually modify what they want. > >> Sage is indeed different in that the technology is constructed to >> discourage to "developer"/"end user" dichotomy that you mention >> above. Anyone who is at all serious about using Sage is also a >> programmer, since the user interface to Sage is a programming >> language. > > Sorry, but > > Mission: Creating a viable free open source alternative to > Magma, Maple, Mathematica and Matlab. > > also expresses that you care about people who just want to use Sage, not > primarily extend it. > >> Because the goals of the Sage project require massive >> people-power, Sage provides every user with an easy environment in >> which to do development. > > I hope you understood, that I was mentioning that opportunity for people > to change sage since even a binary sage comes with sources, because I > appreciate it. I was thinking about a somewhat more GNU-like build > standard without losing this sage feature. > > For the following... correct me if I see something wrongly. > > * Sage currently comes either as a source or binary tarball. > * To develop sage, one downloads the sourc tarball and then develops > inside the devel/sage-xyz directory. > * As I learned today devel/sage-main is actually called the Sage-Library > and available as an spkg. > * There is no repository for the source code (i.e. source tarball minus > the directories spkg, devel, data, examples, local, (ipython). > * Suppose such a repository would exist. Call it "sage-bare". > * Add the code from http://hg.sagemath.org/scripts-main/ into the local > directory of sage-bare and call the whole thing "sage-bootstrap". > > So what should sage-bootstrap (when compiled) do. > 1) (configure) Test and setup the environment (provide sage-env). > 2) (make step: download) Consult a certain config file to figure out > about all the other parts that are not yet on the local machine. I > imagine that all these other parts are, in fact spkgs. The config file > would list the spkg together with a (known good) version and some places > where to try to download these packages from. > 3) (make step: build) Delegate the installation of the .spkg to the > spkg-install of the corresponding spkg. > 4) (make install step) Move all installed spkg's into the directory > given via --prefix at configure time. > > Stopping after 2) gives all the files that should be packed into a sage > source tarball. > > Stopping after 3) gives the binary distro. > > Step 4) is for people who don't want to develop any further on sage, > i.e. system administrators can install Sage into /usr/local. > > Not performing step 4) or just keeping all that is there after step 3), > should give (after putting the "sage" script into the PATH) a working > Sage and a Sage development environment in exactly the same way as it is > now. > > The difference to the current sage is the not yet existing > "sage-bootstrap" *repository*. Tags inside that repo mark the sage releases. > > "sage-bootstrap" is basically responsible for setting what is now > "sage-env" for all the other spkgs and it brings the sage script under > revision control. Furthermore it should contain code to download other > spkgs. Not a big deal, eh? > > Comments?
I wonder if it would be a good idea to revisit this discussion in a 2 or 3 months when you've been much more familiar with Sage? -- William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
