Thomas Klausner <tk%giga.or.at@localhost> writes: > py-dateutil-2.0 is out, but it only supports python-3.x. The author > says that python-2.x users should stay at the previous version 1.5, > the current pkgsrc version. > > I'm not sure how to get py-dateutil-2.0 into pkgsrc. If I make it a > separate package, all packages depending on it will have to use > separate DEPENDS lines for py2 and py3. > > If on the other hand I set MASTER_SITES and DISTFILES depending on > PYPKGPREFIX, the version number of the package will differ between py2 > and py3 and I expect that bulk builds won't like that. This is a bit of a mess. It strikes me as unreasonable of a python package to drop 2.x support; while 3.x has been around for a while, I haven't yet perceived the "2.x is old and crufty and anyone using it is lame for not having updated" vibe at all, let alone strongly. However, I expect that we are going to see more of this. My inclination would be to add some mechanism to express a dependency on dateutil that gets resolved to the current package for 2.x and to py3-dateutil (or py-dateutil20) for 3.x. This could be with a line in the depending package, or a metapackage that switches based on python version, or some file in lang/python that simply has list with members like dateutil time/py-dateutil time/py-dateuti20 and then a macro that basically says "depend on dateutil". This is sort of like metapackage, except the metapackages wouldn't actually exist, at install time or in the source tree.
Attachment:
pgp3s7c77tK_q.pgp
Description: PGP signature