Change design of py-* ruby-* ports

[Chris Rees]

On 26 April 2013 08:39, David Demelier <demelier.david at gmail.com> wrote:
> 2013/4/25 Marcus von Appen <mva at freebsd.org>:
>> 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/bsd.python.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

WITH_PYTHON_VERSION= 27 32

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.

Chris