On Wed, Nov 16, 2011 at 5:09 PM, Remi Pointel <[email protected]> wrote: > Hi, > > this is the diff to update python.port.mk to permit to have both Python 2.x > and 3.x working on OpenBSD. > > How it works: > 1) Python2 port > - all ports existing don't need to change, they still build with Python 2 > > 2) Python2 and Python3 port > - if you know that a port (and its dependencies...) work with Python 3 && > Python 2, you just need to add: > IS_PY3 = Yes for all the ports. Be carefull to add ${MODPY_FLAVOR} to your > dependencies (see examples at the end). > Next, to build your port you will need to precise the correct flavor: python3. > > In this case, you must be very carreful with the conflict of the PLIST. If > your port is a library, there is often no problems, but you will have problem > with binaries/doc/examples/wub/... > So you will have to "play" with post-install, in moving files which are > conflicting by suffixing it (see examples at the end). > FYI the port built with python3 will replace the prefix py- by py3-. > > 3) Python3 port > - if you know that a port (and its dependencies) work with Python 3 only, you > just need to add: > IS_PY3 = Only, and it will automatically build this port with Python 3. > FYI the port built with python3 follow the same logic that in python2, so if > the port PKGNAME begins with py- it will automatically be replaced by py3-. > > > More details about modifications needed: > - remove the devel/py3-distribute, not used and useless to have py3 in the > dir name (maybe a quirks thing to permit distribute -> py3-distribute? If not > used actually, are modifications in quirks needed?) > - some people don't want to replace py-setuptools by py-distribute, so keep > py-setuptools (Python 2 only). > - add the port devel/py-distribute, only used with Python3 ports (IS_PY3 = > Only, will have the py3-distribute FULLPKGNAME. I attached the diff between > actual py3-distribute and what we want, easier to understand). > - remove the MODPY_DISTRIBUTE, useless. Keep the MODPY_SETUPTOOLS only, > easier to maintain, even if we used distribute or setuptools after, it's not > the problem of the porters. > > > So, if your ports use: > 1) Python 2 only > - nothing to change > > 2) Python 2 and Python 3: > - add IS_PY3 = Yes > - add to your *_DEPENDS : ${MODPY_FLAVOR}, without comma (example: > BUILD_DEPENDS: devel/py-distribute${MODPY_FLAVOR}). > - make sure your PLIST will not be in conflict by adding special tasks in > post-install. Example: > post-install: > mv ${WRKINST}/${LOCALBASE}/foo/bar > ${WRKINST}/${LOCALBASE}/foo/bar${MODPY_BIN_SUFFIX} > > If you use the default FLAVOR (Python 2), MODPY_BIN_SUFFIX is "", so no > modifications for people who use the default. If you use the FLAVOR Python 3, > MODPY_BIN_SUFFIX = 3. > Add ${MODPY_BIN_SUFFIX} to your PLIST. > > 3) Python 3: > - add IS_PY3 = Only > > I think the best thing to do now is to patch python.port.mk and run a full > bulk build to see if all ports are ok :).
I think this approach makes sense for python. port.ruby.mk automatically allows building with all four supported ruby implementations by default, and that means if changes to any ruby implementation require a bump to all dependencies, you have to bump pretty much all ruby ports since you can't set REVISION for individual FLAVORs. This approach avoids that issue, so an upgrade from python 3.2 to 3.3 would only require you bump the ports that are specifically set to build with python 3. The only downside is if you want to support another python implementation (i.e. jython or pypy), adding another set of IS_* variables to every port is kind of a pain. I don't think there are any commonly used alternative python implementations, though, so it may not be an issue. Jeremy
