...at the same time. Let's see, what we can do now (based on the ports, ignoring pkg here for now):
- switch the default python version (for all ports) or the python
version for a single port
- properly install and deinstall all ports for python 2.x
- properly install and deinstall ports for python 3.x, that are
explicitly marked as such and which deal with __pycache__ correctly
- Install the same port for different python versions as long as it
* uses PYTHON_PKGNAMEPREFIX/PKGNAMESUFFIX to create a unique PKGNAME
* its data/doc/etc/bin/whatever files use a unique name for different
python versions (a minority, if there are some)
Putting all this together, probably 10 to 20 percent of the python ports
are currently capable of being installed for muliple CPython instances
at the same time.
What do we need to deal with? I am only looking at CPython for the
moment, leaving PyPy out for now.
Use PKGNAMEPREFIX/SUFFIX for python ports
- this is a clean up task (which should be done regardless of everything
else). Some python modules miss the prefix, making it impossible to
install them for multiple python versions at the same time
Handle byte-compiled files properly:
- rm@ provided a __pycache__ plist post target, which can fix the
deinstallation for the majority of python ports, when the user wants
python 3.x. [0]
- I provided a plist post target to deal with .pyc files automatically
instead of storing them in the plist files. [1]
Handle data and doc files properly:
- python ports installing shared files must not create conflicts at
installation or deinstallation time. DATADIR and DOCDIR should include
the PYTHON_PKGNAMEPREFIX (or SUFFIX). Since most ports should be
DATADIR and DOCDIR aware, that change might have a rather small impact
on some ports
- application binaries should receive a prefix or suffix based on
PYTHON_PKGNAME(PREFIX|SUFFIX). The currently active
PYTHON_DEFAULT_VERSION might indicate, which binary shall by symlinked
to a prefixed or suffixed name. This is likely to affect several ports
and involves some Makefile hacking or an additional
PYTHON_APPLICATION_BINARIES=
variable, which can be dealt with in bsd.python.mk. File names
assigned to that variable are automatically symlinked in a do-install
hook
- Other files, especially configuration files (ETCDIR, etc.) may need
specialy consideration, but should become PYTHON_PKGNAMESUFFIX-aware.
This is likely to require some patching and will have an impact on
some python ports.
Support for non-CPython implementations:
- A mid-term goal should be to offer support PyPy in USE_PYTHON, etc.
This can introduce a new PYTHON_PKGNAMEPREFIX and SUFFIX and should
have only a minimal impact on implementing the change, once everything
else has been done.
Those should be the most important tasks to enable proper support for
multiple Python versions. Regarding the order, I would recommend:
1) Use PKGNAMEPREFIX/SUFFIX for python ports
should be done within only a few days and also should not have any
impact on the existing ports tree infrastructure or package building
2) Handle byte-compiled files properly
quite large clean-up task, since this involves plist changes for all
affected ports. An exp-run would be required to ensure that no port
has been forgotten and the add-plist* hook(s) work correctly
3) Handle data and doc files properly
hard to say, since this will also involve testing the ports to find
all flaws.
4) Support for non-CPython implementations
A rather small task; will mainly involve marking ports as not working
under PyPy.
[0] http://lists.freebsd.org/pipermail/freebsd-python/2013-January/005050.html
[1] http://people.freebsd.org/~mva/pyc_compile.bsd.python.mk.patch
Feedback is highly appreciated. If there are no larger objections, we
can and should start with those tasks as soon as possible.
Cheers
Marcus
pgpzcneZBVhT6.pgp
Description: PGP signature
