hg repository in spkgs
Kevin Horton
the hard drive with a whole bunch of stuff that a particular user
doesn't need. In this light, it makes sense to provide spkgs that do
not contain hg repositories.
I attempted to install the sage-3.4.2.spkg, and noted that this gave
me an hg repository that took up a large percentage of the space in
the sage directory. I realize that currently these packages come from
the sage project, and spd uses them as-is. But, at some point in the
future, I think it makes sense for spd to develop a script that purges
the repositories from these packages and creates a new set of lean, hg-
free packages.
--
Kevin Horton
Ottawa, Canada
Ondrej Certik
>
> The main attraction to SPD seems to be avoiding the need to fill up
> the hard drive with a whole bunch of stuff that a particular user
> doesn't need. In this light, it makes sense to provide spkgs that do
> not contain hg repositories.
Yes, I realized that too that the ".hg" directory is quite big. For
most of the packages it's small though, as it only versions the
spkg-install script. For "sage", it's big, because it contains the
whole history.
For example for sympy, the git has about 20MB, but the release tarball
(or spkg) only 2MB.
>
> I attempted to install the sage-3.4.2.spkg, and noted that this gave
> me an hg repository that took up a large percentage of the space in
> the sage directory. I realize that currently these packages come from
> the sage project, and spd uses them as-is. But, at some point in the
> future, I think it makes sense for spd to develop a script that purges
> the repositories from these packages and creates a new set of lean, hg-
> free packages.
Yes, I made it:
http://code.google.com/p/spdproject/issues/detail?id=21
I think that for most of the packages it doesn't matter much, except
"sage" and maybe a few others.
Ondrej
mabshoff
On May 19, 10:52 am, Ondrej Certik <ond...@certik.cz> wrote:
Sage library you will have to take the history. Otherwise anybody
complaining about issues will get the analog reply to the people
running the Debian build of sage, i.e. install the real Sage and try
again.
> Ondrej
Cheers,
Michael
Ondrej Certik
I'll update the issue, once google code stops being read only.
Ondrej
Brian Granger
should keep them there to maintain maximal compatilibity with Sage. I
think we should (as much as possible) be using the same exact spkgs as
Sage. If we update spkgs that Sage has, we should use the hg repo and
(eventually) feed the modified spkg back to Sage (if they accept).
Cheers,
Brian
William Stein
The problem is that that sage-x.y.z spkg is currently badly designed
and not at all up to the spec of how Sage spkg's should be laid out.
The contents of the Sage spkg should be:
spkg-install src/ SPKG.txt .hg
where the .hg directory is tiny. Instead the contents are:
wstein@sage:~/sage/spkg/standard/sage-3.4.2$ ls
bundle doc install module_list.py pull setup.py
spkg-delauto
c_lib export MANIFEST.in PKG-INFO sage-push
spkg-debian-maybe spkg-dist
.hg
where the .hg is huge.
This is *wrong* and is this way for historical reasons only. I
would love for this to be fixed.
What *should* be the case is that everything listed above should be in
an src/ directory.
If you spd guys can fix this (which means fixing the spkg-dist script
to generate the right thing), that
would be a much appreciated contribution. It's probably a 5-line
change (famous last words).
Regarding .hg's and removing them, it would in fact be very beneficial
to have a script that removes hg repos from spkg's. I would to be
able to do "sage -rm_hgs foo.spkg" (or something like that), and have
hg repos get stripped out. This is a feature that has been
*specifically* requested by certain paranoid people, since they want
to use Sage and have the import be 100% source code only. The hg
repos are binary, so these people would really like them removed.
That's enough of a reason to do it. The savings in space is also
nice.
Note that this will involve having to add some new logic to Sage in at
least one case -- currently "sage -upgrade" pulls in the changes from
the new sage spkg using the hg repo. This would obviously break if
the .hg repo isn't there. In that case upgrade is impossible and will
fail. This is fine for certain audiences (like we're talking about),
but it is something to be aware of.
William
Ondrej Certik
I see, thanks for the info.
My current priorities are to get SPD polished as it is (e.g. fix the
show stopper bugs), then release femhub, which will be SPD and our
finite elements codes + sparse solvers, in form of spkg packages. Then
I can work on more things, like help fix other spkg packages.
There is one more thing -- the sage package is special in another way
-- it gets installed into $SAGE_ROOT/devel/sage and the main "sage"
scripts knows about it, so e.g. "sage -b" works.
I think I will have to implement this so that it works for any other
spkg package, in particular our FEM solvers, so that I can use our
customized SPD to actually develop those packages too.
Ondrej