Version numbers of sage_scripts, extcode, examples, sagenb
Jeroen Demeyer
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.
François Bissey
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
leif
> > 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
leif
would have on trac (tickets); perhaps both more structure *and*
confusion...
-Leif
Robert Bradshaw
> 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
Jeroen Demeyer
> 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.
Jeroen Demeyer
>> 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.
Robert Bradshaw
> 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
Jeroen Demeyer
> A lot less hassle once it's implemented though.
that scripts can be improved)
Jeroen.
Robert Bradshaw
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
William Stein
+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
leif
> On Wed, Nov 3, 2010 at 1:35 AM, Robert Bradshaw
>
> <rober...@math.washington.edu> 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...
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
Robert Bradshaw
> 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
kcrisman
>
> 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
Jason Grout
>> 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
Jason Grout
> Even better: upgrade to mathjax
See http://trac.sagemath.org/sage_trac/ticket/9774 for work in progress
(helpers welcome!).
Jason
John H Palmieri
> > 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
Jeroen Demeyer
>> 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.