Recent changes cause py-setuptools to be installed for the python version being used. The installation checks prevent py-setuptools being installed for more than one python version at a time. eg py27-setuptools prevents py32-setuptools being installed. I think the previous behaviour saw py27-setuptools and it was used during install. Now I can't install a port set to use python32 or python33 because setuptools is installed for python27. I've created duplicate ports to be able to install py-numpy for multiple python versions but I don't want to start duplicating every python port to support multiple python versions.
On, Wed Dec 18, 2013, Shane Ambler wrote: [...] > Recent changes cause py-setuptools to be installed for the python > version being used. The installation checks prevent py-setuptools being > installed for more than one python version at a time. > > > eg py27-setuptools prevents py32-setuptools being installed. > > I think the previous behaviour saw py27-setuptools and it was used > during install. Now I can't install a port set to use python32 or > python33 because setuptools is installed for python27. > > I've created duplicate ports to be able to install py-numpy for > multiple python versions but I don't want to start duplicating every > python port to support multiple python versions. This is a long-standing issue that the Python team is aware of. In fact, it does not only have an impact on python ports, but on all ports. The root cause is pkg_add, which uses the PKGORIGIN to detect, whether the port is installed. Since py32-setuptools and py27-setuptools both share the same PKGORIGIN (devel/py-setuptools), pkg_add fails. pkg shares the same problem by checking for the PKGORIGIN record, so a switch to pkg would not help you either. Right now there is no solution at hand for that problem, but we are working on it.
Responsible Changed From-To: freebsd-ports-bugs->freebsd-python Over to maintainer(s).
Canonicalise python@ assignment.
This is mostly fixed, just a suggestion before closing. Manual building within ports works but building package repos with poudriere fails. Could man pages be added to the concurrent setting? Could pkg install incorporate the concurrent renaming steps? Using py-numpy as example. The Makefile creates an extra manpage to match the default py version. When building packages with poudriere if I use a set which specifies py27 as default and build py-numpy then build again with with py34 as default, the two packages can't be installed together. If pkg install performed the concurrent renaming step this could work.
The problem is not about man pages, but about how you configure poudriere. There can be only one default python version at any time, which is the reason, why your approach does not work. The correct approach for your poudriere environment would be to build packages with the proper default python version and to build packages with a user-supplied PYTHON_VERSION setting. If you build packages for python2.7 as default and python3.4 as default, packages may conflict, since e.g. the f2py binary would link to f2py-2.7 and also to f2py-3.4 (or the man page or the docs, etc.). A correct poudriere configuration could look like this: /usr/local/etc/poudriere.d/make.conf: PYTHON_DEFAULT_VERSION=python2.7 /usr/local/etc/poudriere.d/python34-make.conf: PYTHON_DEFAULT_VERSION=python2.7 PYTHON_VERSION=python3.4 To build packages for your default, just invoke poudriere without a set option, as you are used to. To build packages for python3.4, add the set option: poudriere ... -z python34 ...
OK I shoulda thought of setting PYTHON_VERSION But man pages could still be added to concurrent adjustments instead of each port manually renaming them.