#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: |
Description (last modified by )
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)
Change History (9)
comment:1 Changed 11 years ago by
- Cc timdumol jhpalmieri mhansen added
- Description modified (diff)
- Status changed from new to needs_review
comment:2 Changed 11 years ago by
- Description modified (diff)
Replaced the spkg with a corrected one (version names in SPKG.txt
).
comment:3 follow-up: ↓ 4 Changed 11 years ago by
- 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.
comment:4 in reply to: ↑ 3 ; follow-up: ↓ 6 Changed 11 years ago by
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
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
- 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.spkgThe 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
- 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
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.
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: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