Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#10423 closed defect (fixed)

Upgrade Jinja2 to version 2.5.5 (latest upstream)

Reported by: leif Owned by: tbd
Priority: blocker Milestone: sage-4.6.1
Component: packages: standard Keywords: Sphinx download jinja2 spkg
Cc: jdemeyer, timdumol, jhpalmieri, mhansen Merged in: sage-4.6.1.alpha3
Authors: Leif Leonhardy Reviewers: Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by jdemeyer)

The new Sphinx version in Sage 4.6.1.alpha2 (1.0.4, #10118, #10350) requires Jinja2 >= 2.2, while in Sage we currently have version 2.1.1, which triggers undesired downloads during the build.


jinja2-2.5.5.p0 (Leif Leonhardy, December 3rd, 2010)

  • #10423: Upgrade to version 2.5.5, as Sphinx (1.0.4) requires a version >=2.2 (cf. #10350).
  • Some clean-up, dependencies added.

Dependencies

  • Python (>= 2.4)
  • setuptools (or distribute)
  • Pygments (according to 'spkg/standard/deps')
  • docutils (dito, as a note only)

New spkg: http://sage.math.washington.edu/home/jdemeyer/spkg/jinja2-2.5.5.spkg

md5sum: 0770c56a50c7c4ab5e926dc45ba4246f jinja2-2.5.5.p0.spkg

Attachments (1)

jinja2_jdemeyer.patch (1.1 KB) - added by jdemeyer 11 years ago.
Patch between Leif's and my spkg

Download all attachments as: .zip

Change History (9)

comment:1 Changed 11 years ago by leif

  • Cc timdumol jhpalmieri mhansen added
  • Description modified (diff)
  • Status changed from new to needs_review

Perhaps we could clarify the dependencies; the web page just says Python and setuptools (or distribute).

Also, spkg/standard/deps lacks an explicit dependency on these, instead lists Pygments:

$(INST)/$(JINJA2): $(BASE) $(INST)/$(PYGMENTS) $(INST)/$(PATCH)
        $(INSTALL) "$(SAGE_SPKG) $(JINJA2) 2>&1" "tee -a $(SAGE_LOGS)/$(JINJA2).log"

There's also:

# For reference and for when the setuptools problem is solved, here
# are the actual dependencies:
#
# sagenb: python pexpect twisted jinja2 sphinx docutils setuptools
# sqlalchemy: python setuptools
# sphinx: docutils jinja2 pygments
# jinja2: python docutils setuptools
# pygments: python setuptools
# twisted: python python_gnutls setuptools
# zodb: python setuptools

comment:2 Changed 11 years ago by leif

  • Description modified (diff)

Replaced the spkg with a corrected one (version names in SPKG.txt).

comment:3 follow-up: Changed 11 years ago by jdemeyer

  • Description modified (diff)
  • Keywords jinja2 spkg added
  • Reviewers set to Jeroen Demeyer

I've made some very minor changes, dropped .p0 from version number and made spkg-install executable. New spkg: http://sage.math.washington.edu/home/jdemeyer/spkg/jinja2-2.5.5.spkg

If somebody can review my changes, positive_review.

Changed 11 years ago by jdemeyer

Patch between Leif's and my spkg

comment:4 in reply to: ↑ 3 ; follow-up: Changed 11 years ago by leif

Replying to jdemeyer:

I've made some very minor changes, dropped .p0 from version number and made spkg-install executable. New spkg: http://sage.math.washington.edu/home/jdemeyer/spkg/jinja2-2.5.5.spkg

The p0 was intentional, as IMHO every Sage package should have a "patch" level, be it zero for the first spkg in a new upstream series, to avoid confusion with (vanilla) upstream tarballs and packages.

(I'm not sure if everybody knows one can often simply change the extension of an upstream tarball and [try to] install it as is into Sage, with the usual Sage commands.)

Almost every distribution prepends its own versioning to package names.


If somebody can review my changes, positive_review.

Really minor, no operational effect, so positive review for those changes.

P.S.: Fortunately(?) sage-spkg does chmod +x, otherwise I would have noticed that myself. ;-)

comment:5 Changed 11 years ago by leif

P.P.S.: (For other tickets as well:) You don't have to add keywords that are already contained in the ticket's title; also case doesn't matter as far as I know. Substrings also match.

The best trac "keywords" I've found so far are "r" and "64". :D

I really wonder if anyone will ever search for these, and if so, I strongly doubt he/she will [quickly] find what he/she was looking for...

comment:6 in reply to: ↑ 4 Changed 11 years ago by jdemeyer

  • Status changed from needs_review to positive_review

Replying to leif:

Replying to jdemeyer:

I've made some very minor changes, dropped .p0 from version number and made spkg-install executable. New spkg: http://sage.math.washington.edu/home/jdemeyer/spkg/jinja2-2.5.5.spkg

The p0 was intentional, as IMHO every Sage package should have a "patch" level, be it zero for the first spkg in a new upstream series, to avoid confusion with (vanilla) upstream tarballs and packages.

Upstream tarballs and packages don't have an .spkg extension, so I don't think there is much confusion possible.

About the naming: it seems there are no rules for this. I would personally always add a patch level if the package contains patches, no patch level otherwise (as is the case with Jinja2).

comment:7 Changed 11 years ago by jdemeyer

  • Merged in set to sage-4.6.1.alpha3
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:8 Changed 11 years ago by leif

Replying to jdemeyer:

Replying to leif:

The p0 was intentional, as IMHO every Sage package should have a "patch" level, be it zero for the first spkg in a new upstream series, to avoid confusion with (vanilla) upstream tarballs and packages.

Upstream tarballs and packages don't have an .spkg extension, so I don't think there is much confusion possible.

An .spkg is essentially the same as a .tar, .tar.gz or .tar.bz2, so the extension doesn't really matter, except that for dealing with an .spkg you have to modify filename completion.

So a "real" spkg, with src/, SPKG.txt and spkg-install etc. should have a different basename, which should be the upstream name (unfortunately not always the case) plus Sage's addendum, .pX, to distinguish its content / structure.

As said above, you can also directly install some vanilla upstream packages if you only change the extension (from e.g. .tar.bz2 to .spkg); these should clearly be distinguishable by lacking a Sage "patch level". (You can of course also rename spkgs to .tar.bz2 or create links just to make handling them easier. ;-) )


About the naming: it seems there are no rules for this. I would personally always add a patch level if the package contains patches, no patch level otherwise (as is the case with Jinja2).

This is an endless discussion (some even say there shouldn't be p0's, but only p1's and up).

IMHO we should use p0 for the first package (new or upgraded to a newer upstream version) if there are no actual patches to upstream source code, p1 otherwise, i.e. if we still have to apply patches though upstream is fresh. (Some even start without a patch level despite we patch upstream.)

"Downgrading" the patch level, or keeping it for a long time though there have been many changes during the review process is the worst thing. I don't know how many x.y.z.pK.oldN spkgs I have. At least posting the new md5sum gets common now.

Note: See TracTickets for help on using tickets.