2 views

Skip to first unread message

Nov 2, 2010, 7:26:57 AM11/2/10

to sage-devel

This is a topic which I already touched in the "Merging tickets into

sagenb" thread, but I believe the discussion was not finished.

sagenb" thread, but I believe the discussion was not finished.

Currently, every new Sage version has a new version of the following

spkgs: sage, sage_scripts, extcode, examples. However, it is likely

that not all those spkgs change in every version.

So my proposal would be:

* Only update these spkgs whenever the actual code changes. Use the

Sage version as version number. This means that sage-4.6.1.alpha1 may

contain extcode-4.6.1.alpha0.spkg if extcode is not updated in

sage-4.6.1.alpha1.

* Also add sagenb to the list of spkgs handled this way.

How to implement:

* Simplify sage-sdist such that it does not package sage_scripts,

extcode, examples (or make a sage-sdist-light script which does this).

* Merge sage_scripts, extcode, examples in the merger script.

Jeroen.

Nov 2, 2010, 4:55:42 PM11/2/10

to sage-...@googlegroups.com

necessary. In the case of sage_script I believe the sage banner is updated

to reflect the version each time. Otherwise there are little changes usually.

If you want to go that route, I would suggest that the versioning of these

packages should be completely separate from the sage spkg, same as the

notebook.

My own opinion of course.

Francois

Nov 3, 2010, 12:35:04 AM11/3/10

to sage-devel

On 2 Nov., 21:55, François Bissey <f.r.bis...@massey.ac.nz> wrote:

> > This is a topic which I already touched in the "Merging tickets into

> > sagenb" thread, but I believe the discussion was not finished.

>

> > Currently, every new Sage version has a new version of the following

> > spkgs: sage, sage_scripts, extcode, examples. However, it is likely

> > that not all those spkgs change in every version.

>

> > So my proposal would be:

> > * Only update these spkgs whenever the actual code changes. Use the

> > Sage version as version number. This means that sage-4.6.1.alpha1 may

> > contain extcode-4.6.1.alpha0.spkg if extcode is not updated in

> > sage-4.6.1.alpha1.

> > * Also add sagenb to the list of spkgs handled this way.

>

> > How to implement:

> > * Simplify sage-sdist such that it does not package sage_scripts,

> > extcode, examples (or make a sage-sdist-light script which does this).

> > * Merge sage_scripts, extcode, examples in the merger script.

>

> As far as I am concerned it would nice not to bump packages more than

> necessary.

+N
> > This is a topic which I already touched in the "Merging tickets into

> > sagenb" thread, but I believe the discussion was not finished.

>

> > Currently, every new Sage version has a new version of the following

> > spkgs: sage, sage_scripts, extcode, examples. However, it is likely

> > that not all those spkgs change in every version.

>

> > So my proposal would be:

> > * Only update these spkgs whenever the actual code changes. Use the

> > Sage version as version number. This means that sage-4.6.1.alpha1 may

> > contain extcode-4.6.1.alpha0.spkg if extcode is not updated in

> > sage-4.6.1.alpha1.

> > * Also add sagenb to the list of spkgs handled this way.

>

> > How to implement:

> > * Simplify sage-sdist such that it does not package sage_scripts,

> > extcode, examples (or make a sage-sdist-light script which does this).

> > * Merge sage_scripts, extcode, examples in the merger script.

>

> As far as I am concerned it would nice not to bump packages more than

> necessary.

> In the case of sage_script I believe the sage banner is updated

> to reflect the version each time. Otherwise there are little changes usually.

version number outside of the Sage scripts repo. (Completely

incidentally, #9434 is related. Both are still a bit work in progress

though, slightly dragging.)

> If you want to go that route, I would suggest that the versioning of these

> packages should be completely separate from the sage spkg, same as the

> notebook.

> My own opinion of course.

-Leif

Nov 3, 2010, 12:52:55 AM11/3/10

to sage-devel

would have on trac (tickets); perhaps both more structure *and*

confusion...

-Leif

Nov 3, 2010, 3:57:36 AM11/3/10

to sage-...@googlegroups.com

On Tue, Nov 2, 2010 at 4:26 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

> This is a topic which I already touched in the "Merging tickets into

> sagenb" thread, but I believe the discussion was not finished.

>

> Currently, every new Sage version has a new version of the following

> spkgs: sage, sage_scripts, extcode, examples. However, it is likely

> that not all those spkgs change in every version.

>

> So my proposal would be:

> * Only update these spkgs whenever the actual code changes. Use the

> Sage version as version number. This means that sage-4.6.1.alpha1 may

> contain extcode-4.6.1.alpha0.spkg if extcode is not updated in

> sage-4.6.1.alpha1.

> * Also add sagenb to the list of spkgs handled this way.

> This is a topic which I already touched in the "Merging tickets into

> sagenb" thread, but I believe the discussion was not finished.

>

> Currently, every new Sage version has a new version of the following

> spkgs: sage, sage_scripts, extcode, examples. However, it is likely

> that not all those spkgs change in every version.

>

> So my proposal would be:

> * Only update these spkgs whenever the actual code changes. Use the

> Sage version as version number. This means that sage-4.6.1.alpha1 may

> contain extcode-4.6.1.alpha0.spkg if extcode is not updated in

> sage-4.6.1.alpha1.

> * Also add sagenb to the list of spkgs handled this way.

I think it'd be odd to have alpha and release candidate named patches

in an official release. (Even more so than miss-matched numbers...)

> How to implement:

> * Simplify sage-sdist such that it does not package sage_scripts,

> extcode, examples (or make a sage-sdist-light script which does this).

> * Merge sage_scripts, extcode, examples in the merger script.

Even easier, combine sage-scripts, extcode, and examples into the main

Sage repository. That could simplify things a lot and lead to (IMHO)

more and better development and accessibility of those other

components. I still have yet to see any compelling arguments for why

these are separate.

- Robert

Nov 3, 2010, 4:07:15 AM11/3/10

to sage-...@googlegroups.com

On 2010-11-03 08:57, Robert Bradshaw wrote:

> Even easier, combine sage-scripts, extcode, and examples into the main

> Sage repository. That could simplify things a lot and lead to (IMHO)

> more and better development and accessibility of those other

> components.

> Even easier, combine sage-scripts, extcode, and examples into the main

> Sage repository. That could simplify things a lot and lead to (IMHO)

> more and better development and accessibility of those other

> components.

> I still have yet to see any compelling arguments for why

> these are separate.

One argument I can think of (not sure whether it's compelling) is the

size of the packages: sage is 48MB, sagenb is 18MB, extcode is 11M, all

in the top 10 of largest packages. So keeping a natural segmentation

might not be a bad idea.

Also: your solution seems like a lot more work to implement.

Jeroen.

Nov 3, 2010, 4:10:05 AM11/3/10

to sage-...@googlegroups.com

>> As far as I am concerned it would nice not to bump packages more than

>> necessary.

>

> +N

>> necessary.

>

> +N

>> If you want to go that route, I would suggest that the versioning of these

>> packages should be completely separate from the sage spkg, same as the

>> notebook.

>

> +1

If nobody objects, I will try to do this for extcode and examples as

proof-of-concept in sage-4.6.1.alpha1.

Jeroen.

Nov 3, 2010, 4:17:08 AM11/3/10

to sage-...@googlegroups.com

On Wed, Nov 3, 2010 at 1:07 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

> On 2010-11-03 08:57, Robert Bradshaw wrote:

>> Even easier, combine sage-scripts, extcode, and examples into the main

>> Sage repository. That could simplify things a lot and lead to (IMHO)

>> more and better development and accessibility of those other

>> components.

>

>> I still have yet to see any compelling arguments for why

>> these are separate.

> One argument I can think of (not sure whether it's compelling) is the

> size of the packages: sage is 48MB, sagenb is 18MB, extcode is 11M, all

> in the top 10 of largest packages. So keeping a natural segmentation

> might not be a bad idea.

> On 2010-11-03 08:57, Robert Bradshaw wrote:

>> Even easier, combine sage-scripts, extcode, and examples into the main

>> Sage repository. That could simplify things a lot and lead to (IMHO)

>> more and better development and accessibility of those other

>> components.

>

>> I still have yet to see any compelling arguments for why

>> these are separate.

> One argument I can think of (not sure whether it's compelling) is the

> size of the packages: sage is 48MB, sagenb is 18MB, extcode is 11M, all

> in the top 10 of largest packages. So keeping a natural segmentation

> might not be a bad idea.

Keeping sagenb separate makes sense, but keeping things separate based

on size would suggest that sage.* should be split up. 11MB is nothing

these days.

> Also: your solution seems like a lot more work to implement.

Perhaps. A lot less hassle once it's implemented though.

- Robert

Nov 3, 2010, 4:27:58 AM11/3/10

to sage-...@googlegroups.com

On 2010-11-03 09:17, Robert Bradshaw wrote:

> A lot less hassle once it's implemented though.

Which "hassle"? What's the problem with the current setup? (I agree> A lot less hassle once it's implemented though.

that scripts can be improved)

Jeroen.

Nov 3, 2010, 4:35:45 AM11/3/10

to sage-...@googlegroups.com

Nearly every time I've worked on either sage-scripts or extcode, I've

had to submit corresponding patches to the sage library itself. I'd

say this is more than double the work and confusion, and especially

doesn't play well with switching between branches. Not to mention that

working on spkgs outside the main library is less convenient.

- Robert

Nov 3, 2010, 8:45:13 PM11/3/10

to sage-...@googlegroups.com

+1 to Robert's suggestion...

>

> - Robert

>

> --

> To post to this group, send an email to sage-...@googlegroups.com

> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com

> For more options, visit this group at http://groups.google.com/group/sage-devel

> URL: http://www.sagemath.org

>

--

William Stein

Professor of Mathematics

University of Washington

http://wstein.org

Nov 4, 2010, 7:45:13 AM11/4/10

to sage-devel

On 4 Nov., 01:45, William Stein <wst...@gmail.com> wrote:

> On Wed, Nov 3, 2010 at 1:35 AM, Robert Bradshaw

>

> <rober...@math.washington.edu> wrote:

monolithic).

It's IMHO better to separate the build parts from the maths.

And cloning even more megs isn't nice either; the devel branches have

grown much.

It's ok /to be able/ to run different branches in parallel, but such

should be optional.

I would also e.g. remove all fonts from the SageNB (and perhaps

MoinMoin) packages; they don't compress well and it doesn't make sense

to have them under revision control. The SageNB repo is full of old,

*deleted* fonts.

-Leif

> On Wed, Nov 3, 2010 at 1:35 AM, Robert Bradshaw

>

> <rober...@math.washington.edu> wrote:

> > On Wed, Nov 3, 2010 at 1:27 AM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:

> >> On 2010-11-03 09:17, Robert Bradshaw wrote:

> >>> A lot less hassle once it's implemented though.

> >> Which "hassle"? What's the problem with the current setup? (I agree

> >> that scripts can be improved)

>

> > Nearly every time I've worked on either sage-scripts or extcode, I've

> > had to submit corresponding patches to the sage library itself. I'd

> > say this is more than double the work and confusion, and especially

> > doesn't play well with switching between branches. Not to mention that

> > working on spkgs outside the main library is less convenient.

>

> +1 to Robert's suggestion...

But that's the opposite of getting more modular (instead, even more
> >> On 2010-11-03 09:17, Robert Bradshaw wrote:

> >>> A lot less hassle once it's implemented though.

> >> Which "hassle"? What's the problem with the current setup? (I agree

> >> that scripts can be improved)

>

> > Nearly every time I've worked on either sage-scripts or extcode, I've

> > had to submit corresponding patches to the sage library itself. I'd

> > say this is more than double the work and confusion, and especially

> > doesn't play well with switching between branches. Not to mention that

> > working on spkgs outside the main library is less convenient.

>

> +1 to Robert's suggestion...

monolithic).

It's IMHO better to separate the build parts from the maths.

And cloning even more megs isn't nice either; the devel branches have

grown much.

It's ok /to be able/ to run different branches in parallel, but such

should be optional.

I would also e.g. remove all fonts from the SageNB (and perhaps

MoinMoin) packages; they don't compress well and it doesn't make sense

to have them under revision control. The SageNB repo is full of old,

*deleted* fonts.

-Leif

Nov 4, 2010, 2:14:05 PM11/4/10

to sage-...@googlegroups.com

On Thu, Nov 4, 2010 at 4:45 AM, leif <not.r...@online.de> wrote:

> On 4 Nov., 01:45, William Stein <wst...@gmail.com> wrote:

>> On Wed, Nov 3, 2010 at 1:35 AM, Robert Bradshaw

>>

>> <rober...@math.washington.edu> wrote:

>> > On Wed, Nov 3, 2010 at 1:27 AM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:

>> >> On 2010-11-03 09:17, Robert Bradshaw wrote:

>> >>> A lot less hassle once it's implemented though.

>> >> Which "hassle"? What's the problem with the current setup? (I agree

>> >> that scripts can be improved)

>>

>> > Nearly every time I've worked on either sage-scripts or extcode, I've

>> > had to submit corresponding patches to the sage library itself. I'd

>> > say this is more than double the work and confusion, and especially

>> > doesn't play well with switching between branches. Not to mention that

>> > working on spkgs outside the main library is less convenient.

>>

>> +1 to Robert's suggestion...

>

> But that's the opposite of getting more modular (instead, even more

> monolithic).

> On 4 Nov., 01:45, William Stein <wst...@gmail.com> wrote:

>> On Wed, Nov 3, 2010 at 1:35 AM, Robert Bradshaw

>>

>> <rober...@math.washington.edu> wrote:

>> > On Wed, Nov 3, 2010 at 1:27 AM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:

>> >> On 2010-11-03 09:17, Robert Bradshaw wrote:

>> >>> A lot less hassle once it's implemented though.

>> >> Which "hassle"? What's the problem with the current setup? (I agree

>> >> that scripts can be improved)

>>

>> > Nearly every time I've worked on either sage-scripts or extcode, I've

>> > had to submit corresponding patches to the sage library itself. I'd

>> > say this is more than double the work and confusion, and especially

>> > doesn't play well with switching between branches. Not to mention that

>> > working on spkgs outside the main library is less convenient.

>>

>> +1 to Robert's suggestion...

>

> But that's the opposite of getting more modular (instead, even more

> monolithic).

Very little (if any) of sage-scripts is useful without the sage

library, and visa-versa, so it's really just an artificial separation,

not real modularity. Extcode and examples are even more intertwined.

> It's IMHO better to separate the build parts from the maths.

Extcode and examples are very much about the math. The scripts not as

much, but lots of the sage library is infrastructure as well.

> And cloning even more megs isn't nice either; the devel branches have

> grown much.

> It's ok /to be able/ to run different branches in parallel, but such

> should be optional.

It would be optional. If you don't want to run branches in parallel,

don't clone.

> I would also e.g. remove all fonts from the SageNB (and perhaps

> MoinMoin) packages; they don't compress well and it doesn't make sense

> to have them under revision control. The SageNB repo is full of old,

> *deleted* fonts.

+1 to that idea.

- Robert

Nov 4, 2010, 2:38:32 PM11/4/10

to sage-devel

>

> Extcode and examples are very much about the math. The scripts not as

> much, but lots of the sage library is infrastructure as well.

>

now no longer necessary. We've been loath to get rid of much of them

easily, though. I know there is discussion of this earlier on this

list as well as on some tickets, but I cannot find them - probably

because 'examples' is a VERY common word and I'm not too good at

directing them Boolean searches there.

- kcrisman

Nov 4, 2010, 2:42:27 PM11/4/10

to sage-...@googlegroups.com

On 11/4/10 1:14 PM, Robert Bradshaw wrote:

>> I would also e.g. remove all fonts from the SageNB (and perhaps

>> MoinMoin) packages; they don't compress well and it doesn't make sense

>> to have them under revision control. The SageNB repo is full of old,

>> *deleted* fonts.

>

> +1 to that idea.

Even better: upgrade to mathjax, which uses real fonts rather than png

images (well, if you strip out the png images and make them an optional

spkg for people to install if they want).

In MathJax, the real fonts are about 2M (for an svg version, an eot

version, and an otf version). The png files for the fonts are another

114 MB, though.

Jason

Nov 4, 2010, 2:45:05 PM11/4/10

to sage-...@googlegroups.com

On 11/4/10 1:42 PM, Jason Grout wrote:

> Even better: upgrade to mathjax

> Even better: upgrade to mathjax

See http://trac.sagemath.org/sage_trac/ticket/9774 for work in progress

(helpers welcome!).

Jason

Nov 4, 2010, 4:19:53 PM11/4/10

to sage-devel

On Nov 4, 11:38 am, kcrisman <kcris...@gmail.com> wrote:

> > Extcode and examples are very much about the math. The scripts not as

> > much, but lots of the sage library is infrastructure as well.

>

> Just for the record, most (all? William's said this) of examples is

> now no longer necessary.

What about extcode? I'm assuming that some of it is active and useful
> > Extcode and examples are very much about the math. The scripts not as

> > much, but lots of the sage library is infrastructure as well.

>

> Just for the record, most (all? William's said this) of examples is

> now no longer necessary.

-- I see activity on some trac tickets for this repo -- but some parts

look old and outdated. There is very little documentation: no README

files to describe the contents of each directory, etc. (For example,

what is sagebuild?) What can we get rid of there?

--

John

Nov 8, 2010, 10:48:32 AM11/8/10

to sage-...@googlegroups.com

On 2010-11-03 05:35, leif wrote:

>> As far as I am concerned it would nice not to bump packages more than

>> necessary.

>

> +N

>> As far as I am concerned it would nice not to bump packages more than

>> necessary.

>

> +N

I have implemented this in ticket #10231, needs_review. With this

ticket applied, the version numbers of extcode and examples will be

independent from the main sage spkg. This also means that the version

numbers of these spkg will not always be increased in every Sage

version. I have not changed sage_scripts, since that is updated anyway

because of sage-banner (is there a ticket for this?).

I should also add that some people prefer to have everything (sage,

sage_scripts, extcode, examples) in one big spkg. I am personally NOT

in favour of this because I can't see a good reason for it.

Jeroen.

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu