Dealing with 2.7 and 3.3 installations

[David Demelier]

2013/7/30 Marcus von Appen <mva at freebsd.org>:
> David, Daniel,
>
> just to take this to python@ and to clarify, what problems are still open
> for you:
>
> - bapt confirmed that the parallel installation of python itself from binary
> packages should work
>   without any problem
> - Installation from the ports tree should work without problems
> - Installation of python modules from the ports tree basically works without
> problems (given that
>   you set the correct make knobs), BUT can create tons of issues, when it
> comes to deinstallation,
>   port dependency detection, etc.
>
> As per my understanding, you both mentioned issues with both, python itself
> and 3rd party packages.
> As said above, python itself should not be any problem. If you ran into any
> issue, please let python@
> know about it (ideally with a reproducible step-by-step description) or
> create a PR.
>
> Regarding the 3rd party modules, I am not sure about the pkg status. Maybe
> bapt can say a word or
> two about whether packages are (planned to or currently) built for different
> python versions or not.
> David, Daniel: if you are currently running into trouble with the 3rd party
> modules, please
> let us know, what your requirements are, so we can discuss different
> solutions top be applied to the
> ports tree and, where applicable, improved support for the pkg builds.
>
> Thanks and cheers
> Marcus
>

The problem is not directly related to python. Let me explain with
details how we bulk build for both python 2.7 and 3.3 using the
poudriere infrastructure.

As you know, to build devel/py-* for python 2.7 and for 3.3, you will
need to call make install and set PYTHON_DEFAULT_VERSION to the
correct one. For us, if I plan to build all ports as packages, the
poudriere script will only build devel/py-foobar for the
PYTHON_DEFAULT_VERSION set, which is still 2.7.

To permit other users to use both 2.7 and 3.3 modules, we need to
create two jails which each build devel/py-foobar one with
PYTHON_DEFAULT_VERSION set to python 2.7 and the other one to
python3.3.

And, because these modules requires lang/python, each of these jail
will build the corresponding interpreter and including the symlink to
/usr/local/bin/python.

So we end with the following:

[Jail python 2.7]
lang/python27 built with /usr/local/bin/python

py27-foobar
py27-otherport
...

[Jail python 3.3]
lang/python33 built with /usr/local/bin/python too

py33-foobar
py33-otherport

And then, thanks to the support of multiple repositories with pkgng.
We are able to install py33-foobar and py27-foobar. But, the python
3.3 interpreter will not be installed because it also wants to install
the symlink.

Bapt successfully installed both interpreter because they were
compiled in the same jail, thus, only one of the both have the
IF_DEFAULT conditional evaluated.

Now I agree that the problem is not related to python itself and more
to pkgng. But if we install the /usr/local/bin/python symlink *only*
if it does not currently exist, we will not being confused of from
which repository should I install python 3.3.

That's why I proposed to avoid the use of that conditional IF_DEFAULT
and use a test-symlink before install so that even if python 3.3 is
built within more than one repositories, it will never conflicts with
other interpreters.

Regards,

-- 
Demelier David