Bringing the python ports into shape

[Marcus von Appen]

Dear all,

the meta-ports are available and we are ready to move on to bring the
python ports into shape for different python versions and (later on)
different python implementations.

There are a couple of issues (in order to be done) within the ports tree
to sort out before moving on:

- bsd.python.mk private variables are used in port Makefiles
  This especially relates to the usage of _PYTHON_VERSION within several
  ports and needs to be changed to PYTHON_VERSION.
  This is a cleanup task that should not have any impact on the ports.

- USE_PYTHON vs. PYTHON_VERSION. There is no explicit need for a port to
  set PYTHON_VERSION to enforce a certain python version. If a port
  needs this, it should use USE_PYTHON=<version> instead.
  PYTHON_VERSION shall still exist as readonly variable, but not
  be reassigned by port Makefiles.
  This is a cleanup task, which should lead to a more clear
  bsd.python.mk variable usage within the ports.

- fix ports not to use `python` as command at build and in some cases
  run-time (see below for the problems with that)

- Introduce support USE_PYTHON=2|3
  If a port does not care about a specific Python minor release, it
  should pull in the meta ports wherever possible. This is only a
  cosmetic behaviour to avoid cross-dependency problems with ports
  asking for different python versions (see below for the problems
  behind the scenes)

- enhance USE_PYTHON=yes to pull in lang/python and rely on whatever the
  user specified as default python version. As before, a cosmetic change
  to get rid of the current workaround that always pulls in lang/python.


"The problems with that" / "The problems behind the scenes"

Some ports ask for `python` at build or run-time. This is plainly wrong
for about 99 percent of the ports and only worked in the past, because
at least one python port installed itself as bin/python and noone
changed the default python version with using a lot of ports at the same
time. It is wrong insofar as it relies on the assumption that each
port using `python` works with the current version that identifies
itself as `python`.

Let's assume to have a Python C extension installed (e.g. one of the
million py-XXX ports installing .so files) for the current default
version 2.7. The .so module links against libpython2.7.so, stuff is
installed in lib/python2.7/site-packages, scripts however use
#!/usr/bin/env python and rely on the .so module. Changing the default
python to a different python version will cause the script to be unable
to work anymore, for obvious ABI compatibility reasons.

Thus, every port installing stuff into site-packages or linking against
the python libraries _must_ use the explicit python version for scripts,
binaries and whatnot.

Some ports install scripts without actually using Python itself
(e.g. x11-toolkits/gtk20). For those, it must be ensured that the
scripts work for different python versions without modification or they
have to be changed to use either a meta port python version (python2 or
python3) or an explicit python version.

Fixing ports using `python` is not as hard as it sounds, in my
opinion. Thanks to Uses/shebangfix.mk and the possibility to override
python_OLD_CMD and python_CMD in there, we can fix a huge set of ports
simply by adding

    SHEBANG_FILES= <files>

to the port Makefile and

    python_CMD= ${PYTHON_VERSION} (or ${PYTHON_CMD})

to bsd.python.mk. This will leave us with a small set of ports that need
a post-patch target or something similar to be fixed.

The first two cleanup task(s) will start as soon as possible and
hopefully will be done in a week or two.

I'm CC'ing kwm@ within this mail, since he has a vivid interest on that
topic (for getting gnome3 into the tree). Please keep him CC'd within
this thread until he tells us not to.

Cheers
Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-python/attachments/20130823/cdacdd5f/attachment.sig>