2013/4/25 Marcus von Appen <m...@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.
>> 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.
Regards,
--
Demelier David
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
