Enabling ports to be installed for different python versions

[Marcus von Appen]

On, Sat Aug 03, 2013, David Naylor wrote:

> On Saturday, 3 August 2013 12:32:45 Marcus von Appen wrote:
> > ...at the same time.
> >
> > 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
>
> I think not all python based ports should use PKGNAMEPREFIX/SUFFIX.  Those are
> ports who's main contribution is a bin/ and not libraries.  In these cases the
> use of python is largely incidental.  Two example are devel/eric4 (there is an
> eric5 that supports python3) and ports-mgmt/portbuilder.

To be more precise on what I meant: Ports that act mainly as python
modules. If a port installs stuff into site-packages AND is compatible
with multiple python versions, it should be possible to install it for
them and hence it should feature an according prefix or suffix.

portbuilder for example installs a package libpb into site-packages. If I
would want to have to have that packages around in Python2.7 and
Python3.2, I should be able to install it that way.

The resulting package names might be:

portbuilder-py27
portbuilder-py32
...

Ports that require Python, but do not install anything into
site-packages, do not need to be prefixed or suffixed, though. They just
should use the set default interpreter as depedency.

> > 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.
>
> I don't think we need to limit the scope to only PyPy, there is also
> IronPython and Jython (perhaps longer term goals).  I have the following
> suggestions for PYTHON_PKGNAMEPREFIX:
>  - ppyXY for PyPy
>  - p3pyXY for PyPy3
>  - ipyXY for IronPython
>  - jpyXY for Jython
> where XY is the implementation version.

I left out IronPython and Jython intentionally, since they are barely
usable from a module compatibility point of view (especially for Python
2.7+). Thus my current focus is on getting CPython and PyPy (or PyPy3)
up and running as default python interpreters for FreeBSD.

> > 4) Support for non-CPython implementations
> >
> >    A rather small task; will mainly involve marking ports as not working
> >    under PyPy.
>
> Can you please clarify this?  Are you proposing:
>  - marking all ports as not working under PyPy, or
>  - those ports that fail to build/install under PyPy or
>  - those ports that do not run under PyPy (this will require some form of
> testing the ports after installation).

First would be to determine, which ports do not build and install under
PyPy. Ports that do not run under PyPy (might be the case for several
ctypes-based ports as well as several, which build C modules) requires
testing the port interfaces and can be set on demand, if the reports
come in. For now I would assume PyPy to be able to support every port,
that builds and installs cleanly.

> I'll happily act as liaison between the Python/FreeBSD PyPy teams if needed.

I was unaware that there are seperate teams for that ;-). I would
consider PyPy to belong to the FreeBSD Python team as well as Jython,
IronPython, Cython, PyRex...

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/20130803/dde32f62/attachment.sig>