On Fri, Dec 5, 2008 at 2:54 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
> Hello folks,
>
> the extcode repo in Sage is somewhat of a dumping ground what doesn't
> really fit anywhere else. Below is the disk use of all directories
> that aren't more or less empty:
>
> 44K dist
> 36K gap
> 24K images
> 1.2M javascript
> 228K magma
> 52K maxima
> 3.0M notebook
> 1.9M pari
> 400K pickle_jar
> 204K sagebuild
> 16K singular
> 7.2M total
>
> The 3.0 MB notebook is at least size-wise 95% javascript, too. We
> (Jason Grout is doing all the hard work) are in the process of moving
> all the javascript packages we use (jsmath, jquery, ...) to spkgs so
> that the repo will be much smaller in the future while the .hg repo
> information itself will grow by another couple MB. In the end the
> compressed extcode.spkg will be just as large as before the removal.
> And shipping such an amount of basically 3rd party code we checked in
> and then removed seems like a waste of resources. But what to do?
>
> (a) nuke the extrepo and move things into other places. The
> pickle_jar could go into the main Sage repo, the pari scripts into the
> pari.spkg, the images and the notebook code could also be part of the
> main repo. That leaves certain code for Maxima, Singular and Magma in
> search of a place to hang out.
>
> (b) reset the extrepo. This is the less invasive option, but would
> destroy the version history of some of the files. One option here is
> to check in files in the name of the previous main author, but it
> seems like a bad move.
>
> Either way we should do something about the extocde repo. Since the
> doc repo will die in 3.3. it seems like an excellent opportunity to
> finish some long needed cleanup. I could certainly imagine some
> combination of (a) and (b), i.e. the pari data seems to be large
> untouched in a while and the pari.spkg would seem like a canonical
> place for it. Putting those pari scripts and data under revision
> control also seems rather pointless.
>
> Thoughts?
>
I am very opposed to moving any of the code in other languages into
spkg's. I think spkg's should as close as possible approximate the
upstream originals. This is very important for the Debian and other
packaging efforts, and is conceptually much better. For example, Nick
and I were working on the Sage/Magma interface yesterday, and had to
write lots of code that also goes in the data/extcode/magma directory.
Exactly the same thing could have happened with Gap, and it would
have sucked for half our patches to be patches against the Gap spkg.
However, I don't like the current situation either. I'm tempted to
actually propose that we move everything we need that is in extcode to
the main Sage library repo, just like Mike Hansen is moving the docs
of Sage to that repository. Then we delete the extcode spkg and
repository completely.
We would thus have a new subdirectory:
SAGE_ROOT/devel/sage/extcode
with subdirectories for various languages. A big plus to this is
that, e.g., the work Nick and I was doing would involve a single patch
against the main sage library instead of one patch for extcode and one
for the main library.
The main reason the repos are broken up now is just historical and
because our previous revision control system (darcs) seemed to not
scale very well. Mercurial scales fine, and seems to have no problem
at all dealing with the entire massive Sage history, so I think adding
the Sphinx docs and extcode to the main library would be a good move.
So that's my counter-proposal.
-- Wiliam
--~--~---------~--~----~------------~-------~--~----~
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://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
