Change design of py-* ruby-* ports

Chris Rees crees at
Fri Apr 26 19:36:07 UTC 2013

On 26 April 2013 08:39, David Demelier <demelier.david at> wrote:
> 2013/4/25 Marcus von Appen <mva at>:
>> On, Thu Apr 25, 2013, David Demelier wrote:
>>> Hello,
>>> Currently the ports tree has unified ports for python and ruby modules with
>>> origin like databases/py-sqlalchemy. When someone wants to bulk the
>>> ports tree  to create packages the databases/py-sqlalchemy will only
>>> be built against the current python version set in Mk/
>>> (or overriden in make.conf).
>> Or at the command-line for indiviual ports.
>>> This is a very bad design and we should fix that as soon as possible,
>>> we are a lot of people and some portmgr folks included that is not the
>>> best way to  manage python / ruby modules.
>>> Let say I want to install a package, unfortunately this one requires some
>>> python modules that are only working for python 2.7 but me as a developer I
>>> want to develop with python 3, then we are stuck.
>> Correct. This is the general limitation of depending on a package
>> infrastructure for your specific operating system - or the developer's
>> fault, since he did not yet port the module to your specific version -
>> or the maintainer's, since he could not ensure that the port is stabe
>> enough for your favourite version.
>>> What we need to do now, is to move *all* py-* and ruby-* to their respective
>>> versions i.e py27-* and ruby19 (or 18?).
>>> Then we will need to copy all of these and set them to the newer version so
>>> py33 and ruby20.
>> And initiate a hell of repocopying and testing on each minor
>> release. And cause maintainers to have a lot of additional maintenance
>> efforts. And, and, and, ... No, thanks.
> Are you really sure it will need more maintenance? If the unified port
> should be able to build against both 2.7 and 3.3 the port may need
> some couple of .if defined() of the python version to do some things
> that are specific to the python version. This may lead in a lot of
> maintenance pain since you will need to test both python version each
> time you modify something to verify there is no breakage. On the other
> hand having a dedicated port for python 3.3 and python 2.7 will be
> fully clean. And port is cleaner at a glance.

How, exactly?

You are suggesting making multiple ports for the same package, and
suggesting that's simpler???

>>> Also this will remove the breakage of OPTIONS, all of these ports needs the
>>> dirty hack of OPTIONSFILE because of the ${PKGNAMEPREFIX}.
>>> This will blow out the ports tree by adding a lot of ports, but it's the best
>>> way to cover the both version and future bulk generation for users.
>> No, it is not. It is the best way you thought of so far.
>> Your problem description is too unspecific or too easy to solve. Right
>> now it reads as
>> * one shall be able to install py27-, py32-, ... ports (or ruby) in
>>   parallel - fair enough, then we need to fix the following issue along
>>   with some other minor side effects:
>> /usr/ports/devel/py-logilab-common # make PYTHON_DEFAULT_VERSION=python3.2 PYTHON3_DEFAULT_VERSION=python3.2 install
>> ===>  Installing for py32-logilab-common-0.59.0
>> ===>   py32-logilab-common-0.59.0 depends on file: /usr/local/bin/python3.2 - found
>> ===>   Generating temporary packing list
>> ===>  Checking if devel/py-logilab-common already installed
>> ===>   An older version of devel/py-logilab-common is already installed (py27-logilab-common-0.59.0)
>> Cheers
>> Marcus
> For now because of the unified port, as a package builder, I'm unable
> to build both version easily. I'm okay to see other solutions, all I
> want for me is to be able to generate packages and install all python
> module in both versions so we can still use tools that may requires a
> specific python version.

I think a better way is to make the ports install simultaneously to
different versioned Pythons;

something like


that is detected by ports.

Packages would end up with PKGNAMES such as py27+32-, but I don't
think that's a major issue.

Obviously this would only be done in custom repos, or ports-only setups.


More information about the freebsd-ports mailing list