Date: Fri, 26 Apr 2013 20:35:36 +0100 From: Chris Rees <crees@FreeBSD.org> To: David Demelier <demelier.david@gmail.com> Cc: Marcus von Appen <mva@freebsd.org>, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: Change design of py-* ruby-* ports Message-ID: <CADLo839LqcCLYi7Bb7vgFGtHGiHOKXfHhwwj%2B=0JERdZwiwRUw@mail.gmail.com> In-Reply-To: <CAO%2BPfDeQcsAxKxM5GCf=ghRx8k6-yUFJu246L_Jx2TPjrdzrXg@mail.gmail.com> References: <2117909.R5VWH3vbkH@melon> <20130425204236.GA2013@medusa.sysfault.org> <CAO%2BPfDeQcsAxKxM5GCf=ghRx8k6-yUFJu246L_Jx2TPjrdzrXg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 April 2013 08:39, David Demelier <demelier.david@gmail.com> wrote:
> 2013/4/25 Marcus von Appen <mva@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo839LqcCLYi7Bb7vgFGtHGiHOKXfHhwwj%2B=0JERdZwiwRUw>