#9434: Stop greping for a non-existent sage-banner
------------------------+---------------------------------------------------
Reporter: drkirkby | Owner: drkirkby
Type: defect | Status: needs_review
Priority: minor | Milestone: sage-4.6
Component: build | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
------------------------+---------------------------------------------------
Comment(by jhpalmieri):
Replying to [comment:23 leif]:
> Replying to [comment:20 jhpalmieri]:
> > Replying to [comment:17 leif]:
> > > I wouldn't call {{{sage}}} in {{{sage-upgrade}}}.
> >
> > I can see from your other reasons that we need to update the version
number earlier so my solution won't work, but I see no reason, a priori,
not to call {{{sage}}} in {{{sage-upgrade}}},
>
> {{{sage-upgrade}}} isn't "the end" of the upgrade process (it's called
by {{{sage-sage}}}),
> and calling the "new" Sage there can potentially cause more trouble than
we want. So since it's not necessary, I would leave it.
>
> > after the upgrade process has completed, apparently successfully. It
actually tests further whether the upgrade succeeded.
>
> This is done later
Where? sage-upgrade gets called twice in sage-sage, but that's basically
all that happens when you run "sage -upgrade", isn't it? I guess running
it twice means that VERSION.txt may end up being wrong; I'll have to fix
that.
> , and finally calling the new Sage should be up to the user, e.g.
indirectly by building the documentation.
>
> > > Rather than omitting {{{VERSION.txt}}} from the {{{sage_scripts}}}
spkg, I would put the code to update (or better: not overwrite) an
existing {{{VERSION.txt}}} in its {{{spkg-install}}}.
> >
> > Why? In general, copying over all *.txt files is a little dangerous,
and is part of the reason that the file sage-README-osx.txt appears in the
wrong places and isn't currently tracked in any repo.
>
> I didn't say copy {{{*.txt}}} (otherwise checking the presence of an
existing {{{$SAGE_ROOT/VERSION.txt}}} wouldn't make much sense). But
having it there (''not'' in the repo, i.e., in {{{.hgignore}}}) we can
easily extract it before that spkg gets installed, because a new scripts
repo is always there, is relatively small and gets created by {{{sage
-sdist}}} anyway, where the new version and release date are known.
VERSION.txt is written to SAGE_ROOT by sage-sdist, so it's present in the
Sage tarball. It will therefore also be available in the upgrade path.
> > I think if we want to include a file, it should be tracked. If it's
automatically generated, I don't see any reason to include it in a repo.
>
> See above.
>
> > If #9433 ever gets reviewed and merged, then all of the *.txt files in
SAGE_ROOT will be taken out of the scripts repo in any case.
>
> Well, {{{VERSION.txt}}} shouldn't be under revision control.
>
> > > As noted, the version file should be updated ''before''
{{{spkg/install}}} is called (and that's also before a new scripts spkg
gets installed).
> >
> > Right.
> >
> > > We'd have to extract the new version from some newly downloaded
file. (This only works for later Sage versions anyway, unless we handle it
in {{{spkg/install}}}, too.)
> >
> > How about extracting it from VERSION.txt?
>
> Extracting the file from the file itself? You misunderstood me. I meant
we could extract {{{VERSION.txt}}} e.g. from the scripts repo, with
{{{tar}}}.
Although we can't get the release date from it, we could also use the
''file name'' for the main Sage repo, for example.
> > I'm attaching a patch which does this, perhaps not in the optimal way,
but I think it should work.
>
> I'll take a look at it.
Replying to [comment:25 leif]:
> Ok, if we supply a separate file in the upgrade path.
(See above: the file VERSION.txt gets written to SAGE_ROOT by sage-sdist,
so it will be there.)
> The code is a ''bit'' complicated though.
It's straightforward, but long: first you extract the old version from
VERSION.txt, then you download the new VERSION.txt and extract the new
version, then you produce the updated VERSION.txt. I need to check
whether the new version matches the beginning of the old version, in case
this is the second time sage-upgrade is run.
Finally, I think having "UTC" at the end of the date looks a little silly
when it's just a date, no time, but I've included it.
Here's a new patch.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9434#comment:28>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
