On 05/13/11 07:45 PM, kcrisman wrote:
$ export SAGE_PARALLEL_SPKG_BUILD=yes
$ export MAKE='make -j8'
$ make
See the installation guide for information about the relevant environment
variables. I think that we should set SAGE_PARALLEL_SPKG_BUILD to "yes"
automatically -- it works very well, a
> > $ export SAGE_PARALLEL_SPKG_BUILD=yes
> > $ export MAKE='make -j8'
> > $ make
>
> > See the installation guide for information about the relevant environment
> > variables. I think that we should set SAGE_PARALLEL_SPKG_BUILD to "yes"
> > automatically -- it works very well, according to everyo
On Tue, May 10, 2011 at 3:35 PM, John H Palmieri wrote:
>
>
> On Tuesday, May 10, 2011 2:38:38 PM UTC-7, Ondrej Certik wrote:
>>
>> On Tue, May 10, 2011 at 7:19 AM, Volker Braun
>> wrote:
>> > IMHO the list of installed files is an integral piece of package
>> > management
>> > and should explici
> So what you have in mind is:
>
> * automatically generate the list of files from *sequential* builds,
> store it in spkg (or possibly somewhere else)
>
> * use this in all default builds (either parallel or sequential), Sage
> would store the list of files somewhere, and use it for uninstall
>
>
> On Thursday, May 12, 2011 3:18:29 PM UTC-7, Ondrej Certik wrote:
> > On Thu, May 12, 2011 at 5:29 AM, Maarten Derickx
> > wrote:
> > [...]
> >
> > >> What would be the advantage of having it in the SPKG itself?
> > >
> > > That it wil be compatible with parallel building as mentioned earlier.
On Thursday, May 12, 2011 3:18:29 PM UTC-7, Ondrej Certik wrote:
>
> On Thu, May 12, 2011 at 5:29 AM, Maarten Derickx
> wrote:
> [...]
> >>
> >> What would be the advantage of having it in the SPKG itself?
> >>
> > That it wil be compatible with parallel building as mentioned earlier.
> >
> >> L
On Thu, May 12, 2011 at 5:29 AM, Maarten Derickx
wrote:
[...]
>>
>> What would be the advantage of having it in the SPKG itself?
>>
> That it wil be compatible with parallel building as mentioned earlier.
>
>> Like if you want to install two packages that overwrite the same file?
> I don't think w
On May 11, 9:41 am, Ondrej Certik wrote:
> On Tue, May 10, 2011 at 11:23 PM, Maarten Derickx
>
>
>
>
>
>
>
>
>
> wrote:
>
> > On May 10, 9:10 am, Ondrej Certik wrote:.
>
> >> It just occurred to me, that it should be possible to keep the current
> >> SPKG format, and implement uninstall. One j
On 05/10/11 11:35 PM, John H Palmieri wrote:
Does Sage work with parallel installation of packages?
Absolutely. Do:
$ export SAGE_PARALLEL_SPKG_BUILD=yes
$ export MAKE='make -j8'
$ make
See the installation guide for information about the relevant environment
variables. I think that we sho
On Tue, May 10, 2011 at 11:23 PM, Maarten Derickx
wrote:
>
>
> On May 10, 9:10 am, Ondrej Certik wrote:.
>>
>> It just occurred to me, that it should be possible to keep the current
>> SPKG format, and implement uninstall. One just needs to keep track of
>> all files in SPKG_LOCAL, then see what
Maybe the following is also interesting
http://pypi.python.org/pypi/zc.buildout/1.5.2
--
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://grou
On May 10, 9:10 am, Ondrej Certik wrote:.
>
> It just occurred to me, that it should be possible to keep the current
> SPKG format, and implement uninstall. One just needs to keep track of
> all files in SPKG_LOCAL, then see what new files were added + which
> files have changed.
>
> If a file h
On Tue, May 10, 2011 at 7:19 AM, Volker Braun wrote:
> IMHO the list of installed files is an integral piece of package management
> and should explicitly be part of the spkg. Automatically generating it is
> not an option during parallel compilation. There should be a "spkg-files" or
> so in the
On Tuesday, May 10, 2011 2:38:38 PM UTC-7, Ondrej Certik wrote:
>
> On Tue, May 10, 2011 at 7:19 AM, Volker Braun
> wrote:
> > IMHO the list of installed files is an integral piece of package
> management
> > and should explicitly be part of the spkg. Automatically generating it is
> > not an
On Tue, May 10, 2011 at 7:19 AM, Volker Braun wrote:
> IMHO the list of installed files is an integral piece of package management
> and should explicitly be part of the spkg. Automatically generating it is
> not an option during parallel compilation. There should be a "spkg-files" or
That's a go
IMHO the list of installed files is an integral piece of package management
and should explicitly be part of the spkg. Automatically generating it is
not an option during parallel compilation. There should be a "spkg-files" or
so in the spkg that lists them. During single package build one could
On 05/10/11 08:10 AM, Ondrej Certik wrote:
It just occurred to me, that it should be possible to keep the current
SPKG format, and implement uninstall. One just needs to keep track of
all files in SPKG_LOCAL, then see what new files were added + which
files have changed.
Why not something like
On Mon, May 9, 2011 at 4:48 PM, Ondrej Certik wrote:
> On Mon, May 9, 2011 at 4:01 PM, Robert Bradshaw
> wrote:
>> On Mon, May 9, 2011 at 2:57 PM, Ondrej Certik wrote:
> [...]
>>> I was thinking about this a lot yesterday, and there are a lot more
>>> issues to resolve, than it seems at first si
On Mon, May 9, 2011 at 4:01 PM, Robert Bradshaw
wrote:
> On Mon, May 9, 2011 at 2:57 PM, Ondrej Certik wrote:
[...]
>> I was thinking about this a lot yesterday, and there are a lot more
>> issues to resolve, than it seems at first sight. In particular, some
>> packages like Python is doing some
On Mon, May 9, 2011 at 2:57 PM, Ondrej Certik wrote:
> On Mon, May 9, 2011 at 9:11 AM, Robert Bradshaw
> wrote:
>> On Mon, May 9, 2011 at 3:05 AM, Ondrej Certik wrote:
>>> On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
>>> wrote:
On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
>
On Mon, May 9, 2011 at 9:11 AM, Robert Bradshaw
wrote:
> On Mon, May 9, 2011 at 3:05 AM, Ondrej Certik wrote:
>> On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
>> wrote:
>>> On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
> On
On Mon, May 9, 2011 at 3:05 AM, Ondrej Certik wrote:
> On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
> wrote:
>> On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
>>> On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
wrote:
>>>
On Mon, May 9, 2011 at 3:05 AM, Ondrej Certik wrote:
> On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
[...]
>> What about
>> dependencies (e.g. if the version of Cython was updated, would all the
>> stuff depending on Cython get re-compiled?
>
> No. Only the other way round -- if you want to inst
On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
wrote:
> On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
>> On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
>>> On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
>>> wrote:
>>> [...]
Were I to design the system from scratch, I'd put
On 2011-05-08 06:31, Robert Bradshaw wrote:
> But it isn't exposed as an hg repository anywhere
I'm happy to expose whatever as hg repository if somebody explains me
what and how.
> The
> fact that so much is not under (a single) revision control makes this
> harder.
You mean that it's harder to r
On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
> On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
>> On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
>> wrote:
>> [...]
>>> Were I to design the system from scratch, I'd put
>>> all our code (devel/scripts/...) in a single repo, along wi
On Sat, May 7, 2011 at 2:55 AM, Jeroen Demeyer wrote:
> On 2011-05-06 20:26, Robert Bradshaw wrote:
>> And
>> I'd love to have a live head to test and rebase against. Something
>> like the sage merger script, but automated as every ticket on trac
>> with positive review + release manager approval
On 5/6/11 4:21 PM, Ondrej Certik wrote:
Oh, and then people can simply send pull requests to the respective
packages directly. So I think it solves lots of the problems raised in
this thread. For sage, it would have to move to github though, so it
might not be an option.
Bitbucket has pull req
On 2011-05-06 20:26, Robert Bradshaw wrote:
> And
> I'd love to have a live head to test and rebase against. Something
> like the sage merger script, but automated as every ticket on trac
> with positive review + release manager approval + passing on these X
> systems (on top of last previous head)
On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
> On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
> wrote:
> [...]
>> Were I to design the system from scratch, I'd put
>> all our code (devel/scripts/...) in a single repo, along with the
>> top-level files, and a list of dependencies (spkgs)
On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
wrote:
[...]
> Were I to design the system from scratch, I'd put
> all our code (devel/scripts/...) in a single repo, along with the
> top-level files, and a list of dependencies (spkgs). Building sage
> would fetch (locally or remotely) the depende
On Fri, May 6, 2011 at 11:41 AM, Martin Albrecht
wrote:
>> The other problem is that so much isn't under revision control (eg.
>> what versions of spkgs to use), or in multiple repositories that need
>> to be kept in sync. Were I to design the system from scratch, I'd put
>> all our code (devel/sc
> The other problem is that so much isn't under revision control (eg.
> what versions of spkgs to use), or in multiple repositories that need
> to be kept in sync. Were I to design the system from scratch, I'd put
> all our code (devel/scripts/...) in a single repo, along with the
> top-level files
On Fri, May 6, 2011 at 12:12 AM, Keshav Kini wrote:
> Hi Jeroen,
>
> I'd suggest that SPKG authors make their final commit themselves rather than
> just allowing Jeroen's script to do it for them - this keeps the "blame
> history" intact (assuming Jeroen's script doesn't mine people's names from
>
Hi Jeroen,
I'd suggest that SPKG authors make their final commit themselves rather than
just allowing Jeroen's script to do it for them - this keeps the "blame
history" intact (assuming Jeroen's script doesn't mine people's names from
SPKG.txt and commit under those names!).
I sometimes worry
On 5/5/11 4:42 PM, Dr. David Kirkby wrote:
On 05/ 5/11 03:06 PM, Jeroen Demeyer wrote:
Hi all,
I recently adapted the merge scripts to deal with spkg's in a new way.
Further ideas, suggestions, complaints are welcome.
Jeroen.
I've often wondered if it would be possible to safely remove th
On 5/5/11 5:02 PM, Francois Bissey wrote:
I would add on top of that for consideration that SPKG.txt often contains
more info than what you would find in a normal changelog. It often has
special instructions about the package, it is much more info than just a
changelog.
Yes, and +1 for keeping
On 5 May 2011 23:02, Francois Bissey wrote:
>> I suppose for my spkg workflow (mostly Cython) the new spkg doesn't
>> usually involve anything more than swapping out the sources and
>> perhaps adding/removing a patch. Adding an SPKG.txt entry is entirely
>> redundant with the hg commit (if one is
On Thu, May 5, 2011 at 3:02 PM, Francois Bissey
wrote:
>> On Thu, May 5, 2011 at 1:34 PM, Jason Grout
> wrote:
>> > On 5/5/11 3:29 PM, Jeroen Demeyer wrote:
>> >> On 2011-05-05 20:20, Dr. David Kirkby wrote:
>> >>> I like SPKG.txt. Personally I would have called the file "ChangeLog"
>> >>> in
>>
> On Thu, May 5, 2011 at 1:34 PM, Jason Grout
wrote:
> > On 5/5/11 3:29 PM, Jeroen Demeyer wrote:
> >> On 2011-05-05 20:20, Dr. David Kirkby wrote:
> >>> I like SPKG.txt. Personally I would have called the file "ChangeLog" in
> >>> common with just about every other software project, but SPKG.txt
On Thu, May 5, 2011 at 1:34 PM, Jason Grout wrote:
> On 5/5/11 3:29 PM, Jeroen Demeyer wrote:
>>
>> On 2011-05-05 20:20, Dr. David Kirkby wrote:
>>>
>>> I like SPKG.txt. Personally I would have called the file "ChangeLog" in
>>> common with just about every other software project, but SPKG.txt doe
On 5/5/11 3:29 PM, Jeroen Demeyer wrote:
On 2011-05-05 20:20, Dr. David Kirkby wrote:
I like SPKG.txt. Personally I would have called the file "ChangeLog" in
common with just about every other software project, but SPKG.txt does.
I think that summerises the changes much better than what "hg log"
On 2011-05-05 20:20, Dr. David Kirkby wrote:
> I like SPKG.txt. Personally I would have called the file "ChangeLog" in
> common with just about every other software project, but SPKG.txt does.
> I think that summerises the changes much better than what "hg log" does,
> where often there are numerou
On 05/ 5/11 04:47 PM, kcrisman wrote:
Further ideas, suggestions, complaints are welcome.
I agree with the sentiment expressed elsewhere in previous threads that
the changelog should be in the hg log, and not necessarily in the
SPKG.txt file. In other words, I feel like the changes you made
On Thu, May 5, 2011 at 8:47 AM, kcrisman wrote:
>
>> > Further ideas, suggestions, complaints are welcome.
>>
>> I agree with the sentiment expressed elsewhere in previous threads that
>> the changelog should be in the hg log, and not necessarily in the
>> SPKG.txt file. In other words, I feel li
> > Further ideas, suggestions, complaints are welcome.
>
> I agree with the sentiment expressed elsewhere in previous threads that
> the changelog should be in the hg log, and not necessarily in the
> SPKG.txt file. In other words, I feel like the changes you made should
> be reversed---the hg l
On 5/5/11 9:06 AM, Jeroen Demeyer wrote:
Hi all,
I recently adapted the merge scripts to deal with spkg's in a new way.
Most importantly, changes inside a spkg are automatically *committed*
before merging the spkg into Sage (the spkg is extracted, hg commit is
done using a commit message coming
47 matches
Mail list logo
