Date: Thu, 25 Apr 2013 22:21:30 +0200 From: David Demelier <demelier.david@gmail.com> To: freebsd-ports@freebsd.org, florent+FreeBSD-ports@peterschmitt.fr Subject: Re: Change design of py-* ruby-* ports Message-ID: <170867095.QSZPI65LGS@melon> In-Reply-To: <51798E5C.1030802@peterschmitt.fr> References: <2117909.R5VWH3vbkH@melon> <51798E5C.1030802@peterschmitt.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Le jeudi 25 avril 2013 22:13:16 Florent Peterschmitt a =E9crit :
> On 25/04/2013 22:03, David Demelier wrote:
> > Hello,
> >=20
> > Currently the ports tree has unified ports for python and ruby modu=
les
> > with
> > origin like databases/py-sqlalchemy. When someone wants to bulk the=
ports
> > tree to create packages the databases/py-sqlalchemy will only be bu=
ilt
> > against the current python version set in Mk/bsd.python.mk (or over=
riden
> > in make.conf).
> >=20
> > This is a very bad design and we should fix that as soon as possibl=
e, we
> > are a lot of people and some portmgr folks included that is not the=
best
> > way to manage python / ruby modules.
> >=20
> > Let say I want to install a package, unfortunately this one require=
s some
> > python modules that are only working for python 2.7 but me as a dev=
eloper
> > I
> > want to develop with python 3, then we are stuck.
> >=20
> > What we need to do now, is to move *all* py-* and ruby-* to their
> > respective versions i.e py27-* and ruby19 (or 18?).
> >=20
> > Then we will need to copy all of these and set them to the newer ve=
rsion
> > so
> > py33 and ruby20.
> >=20
> > Also this will remove the breakage of OPTIONS, all of these ports n=
eeds
> > the
> > dirty hack of OPTIONSFILE because of the ${PKGNAMEPREFIX}.
> >=20
> > 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 u=
sers.
> >=20
> > Regards,
>=20
> I agree with you. I thought about a PYTHON_VERSION=3D"27 33" variable=
in
> /etc/make.conf, generating each version of the module for each python=
> version if the port is able to do it, but then you may build versions=
of
> module you don't need.
>=20
This is something I think about too, but I'm not sure if it will be eas=
y to=20
generate make package creating two ones for each version?
And if a port requires a py- module but for a specific version, how is =
it=20
possible to share PYTHON_VERSION=3D through dependencies?
> But before (don't know when), it was like you say. py27-, py26, and
> everything merged to py-
>=20
> I was not as implied as now in FreeBSD project but it was surelly
> motivated by something.
--=20
David Demelier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?170867095.QSZPI65LGS>