On Jun 27, 2007, at 12:05 PM, didier deshommes wrote:
> On 6/22/07, William Stein <[EMAIL PROTECTED]> wrote:
>> Could you say something about the fact that currently there is no way
>> to uninstall
>> a SAGE package, since we don't track what files are actually
>> installed. That said,
>> we de
On 6/27/07, didier deshommes <[EMAIL PROTECTED]> wrote:
> It's mostly painless to remove a package if:
> -- you know where all its files are. Most of them are in
> SAGE_ROOT/local/include/ and SAGE_ROOT/local/lib/ . It's pretty to
> figure out what goes where from the spkg-install script.
> -- you
On 6/22/07, William Stein <[EMAIL PROTECTED]> wrote:
> Could you say something about the fact that currently there is no way
> to uninstall
> a SAGE package, since we don't track what files are actually
> installed. That said,
> we definitely *could* implement something simple that stores a list o
This is a great summary of all spkg things! This should definitely be
put into the SAGE docs somewhere.
Brian
On 6/22/07, didier deshommes <[EMAIL PROTECTED]> wrote:
>
> [Apologies, I hit "Send" too soon]
>
> I'm not sure how to write this since it seems to be so "easy" to me.
> I'll start from
[Apologies, I hit "Send" too soon]
I'm not sure how to write this since it seems to be so "easy" to me.
I'll start from the beginning, ie I won't worry about dumbing it down
too much and stating obvious things.
Q: what is a SAGE package?
A: A SAGE package (spkg) is a script that builds an instal
On 6/22/07, didier deshommes <[EMAIL PROTECTED]> wrote:
> > This is unbelievably cool. I just had to hard reinstall IPython
> > because I hacked it too hard and couldn't hg revert to the previous
> > revision. A little tutorial on how one hacks a SAGE package would
> > really help developers suc
On 6/18/07, Nick Alexander <[EMAIL PROTECTED]> wrote:
>
> "didier deshommes" <[EMAIL PROTECTED]> writes:
>
> > On Jun 1, 10:59 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> >> package_dir
> >> spkg-install-- (required) shell script run to install the package
> >> spkg-rebuild -- (o
"didier deshommes" <[EMAIL PROTECTED]> writes:
> On Jun 1, 10:59 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>> package_dir
>> spkg-install-- (required) shell script run to install the package
>> spkg-rebuild -- (optional) download latest version of package from
>>
Thanks, this does clarify what goes on in an update.
> The sage-update script gives an idea of how sage is upgraded from a
> SAGE_SERVER:
> - download the new install script
> - download the new list file. The list file contains all spkgs with
> their version numbers. It is from it that sage kno
> On 6/18/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> > I didn't know SAGE was actually using them. Is this when sage -update
> > is run? My understanding is that the decision to upgrade something
> > was based on the timestamps if the files compared with the stub in the
> > installed directo
On 6/18/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> > Then SAGE wouldn't know that the package had been updated.
> > Those version numbers are used to determine whether it is
> > necessary to install a package.
>
> I didn't know SAGE was actually using them. Is this when sage -update
> is run?
On 6/18/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> I am talking about the both the directory structure that is needed for
> the script/makefiles to function properly:
>
> spkg/
> standard/
> base/
>
> As well as the actual scripts and makefiles (deps, install,
> newest-version, etc) th
On 6/18/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> I didn't know SAGE was actually using them. Is this when sage -update
> is run? My understanding is that the decision to upgrade something
> was based on the timestamps if the files compared with the stub in the
> installed directory. Am I
> > Fantastic! The naming convention for spkgs that includes the .pn
> > post-fix where n labels the spkg version is probably not needed now.
> > My understanding is that label was loosely used as a sort of version
> > control. I think simply having the hg repo for each solves that
> > problem.
On 6/18/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> > I've updated all spkg's so that they now have an hg repo with the
> > directory structure based on the one listed above. Comments and
> > suggestions are welcomed. You can see them here:
> > http://sage.math.washington.edu/home/dfdeshom/cust
> I've updated all spkg's so that they now have an hg repo with the
> directory structure based on the one listed above. Comments and
> suggestions are welcomed. You can see them here:
> http://sage.math.washington.edu/home/dfdeshom/custom/spkg/
Fantastic! The naming convention for spkgs that in
On 6/18/07, didier deshommes <[EMAIL PROTECTED]> wrote:
> I've updated all spkg's so that they now have an hg repo with the
> directory structure based on the one listed above. Comments and
> suggestions are welcomed. You can see them here:
> http://sage.math.washington.edu/home/dfdeshom/custom/sp
On Jun 1, 10:59 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> package_dir
> spkg-install-- (required) shell script run to install the package
> spkg-rebuild -- (optional) download latest version of package from
> web page and recreate the src directory
One other things I forgot to mention that would be nice to have. The
way we are using spkg is to distribute a set of python tools that
overlaps with, but that is not the same as what sage distributes. The
set of tools are are distributing is more focused on numerical
computing. Thus, we include
> The point of spkg's, at least as I seem them, is that they should be
> ridiculously simple, and that anybody can make one with about 5
> minutes of directions.
This was the critical factor for me when I looked at the different options.
> This is -- in my opinion -- in sharp contrast to the sit
On 6/1/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> After looking some at hg queues, I have a few more comments about how
> to handle patching packages sources.
>
> * HG queues help with the issues of maintaining patches against a
> changing upstream source, but it is still a pain and nontrivia
On 6/1/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> * HG queues help with the issues of maintaining patches against a
> changing upstream source, but it is still a pain and nontrivial.
Would the mq extension help? It's an hg extension for managing queues:
http://www.selenic.com/mercurial/wiki/
After looking some at hg queues, I have a few more comments about how
to handle patching packages sources.
* HG queues help with the issues of maintaining patches against a
changing upstream source, but it is still a pain and nontrivial.
* Because of this, I think mercurial queues only make se
I am not too familiar with how gentoo manages all of this, but it does
sounds very similar to the spkg approach in sage:
1. Use original sources from the projects themselves
2. Maintain patches that are applied to that source
3. Use a shell script to build/install
There are some significant d
> > > > For each spkg, there would be a corresponding directory containing the
> > > > spkg-install script and the sage subdirectory (but _not_ the source
> > > > code for the package itself). I think it would be a good idea to
> > > > create a format for the spkgs that is a little more standardi
On Friday 01 June 2007 10:26, didier deshommes wrote:
> On 6/1/07, Joel B. Mohler <[EMAIL PROTECTED]> wrote:
> > The main relation of this to the current discussion is that gentoo solves
> > the patch/mainline problem by distributing patch files which are applied
> > on the user's computer before
On 5/31/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> > > For each spkg, there would be a corresponding directory containing the
> > > spkg-install script and the sage subdirectory (but _not_ the source
> > > code for the package itself). I think it would be a good idea to
> > > create a format
On 6/1/07, Joel B. Mohler <[EMAIL PROTECTED]> wrote:
> The main relation of this to the current discussion is that gentoo solves the
> patch/mainline problem by distributing patch files which are applied on the
> user's computer before the build of the package in question. Sometimes there
> are a
There's something I've been thinking about for awhile about the spkg packages.
It seems relevant to the discussion at hand, but overall I'm not sure that
there is any immediate merit to my comments. I'm a (happy) gentoo user and
one of the principle reasons I'm with gentoo is the package mana
This looks very interesting, I hadn't seen this before. I need to
learn more about hg for sure. Would this approach require having the
source to the upstream project in an hg repo?
On 5/31/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
>
> On 5/31/07, Brian Granger <[EMAIL PROTECTED]> wrote:
>
On 5/31/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> source. This doesn't answer the question of how to maintain those
> patches, that don't get sent back upstream. This definitely needs to
> be addressed.
If I understand correctly, that's what mercurial queues are for:
http://hgbook.red-be
On 5/31/07, didier deshommes <[EMAIL PROTECTED]> wrote:
>
> On 5/22/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> >
> > SAGE developers,
> >
> > As you may know, I have been working on building some new spkgs and
> > have also begun refactoring the spkg build scripts themselves. A few
> > ideas
On 5/22/07, Brian Granger <[EMAIL PROTECTED]> wrote:
>
> SAGE developers,
>
> As you may know, I have been working on building some new spkgs and
> have also begun refactoring the spkg build scripts themselves. A few
> ideas that I would like feedback on:
>
> 1. Creating a repository for the spk
33 matches
Mail list logo
