Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Nov 2015 14:04:27 +1100
From:      Kubilay Kocak <koobs@FreeBSD.org>
To:        Li-Wen Hsu <lwhsu@FreeBSD.org>, FreeBSD Python Team <freebsd-python@freebsd.org>
Subject:   Re: Version specified ports for separated standard Python modules
Message-ID:  <5647F63B.6000303@FreeBSD.org>
In-Reply-To: <CAKBkRUxPbk=gJrsXFrM2MXPBv0b8toWm6p5d5_42ogn4TGgEHw@mail.gmail.com>
References:  <CAKBkRUxPbk=gJrsXFrM2MXPBv0b8toWm6p5d5_42ogn4TGgEHw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 15/11/2015 7:30 AM, Li-Wen Hsu wrote:
> Hi,
> 
> Just read this thread:
> https://lists.freebsd.org/pipermail/freebsd-python/2015-November/009061.html
> 
> This inspire me that we probably can create ports for those separated
> standard Python modules, for each supported Python versions in the
> tree.  That is, adding databases/py3[2-5]-sqlite3, also for
> databases/py-gdbm and x11-toolkits/py-tkinter.  Adding these gives us
> packages and this benefits pkg users, saving their time and space to
> build from scratch.  I also suggest these ports maintained by python@.
> How do the people on this list think?  These ports should be
> straightforward, just slaves port with USES=python:X.Y .  If no one
> objects, I can add them.

This might be the way to go until we have Python 3.x packages built by
default. It would be nice to be *removing* the remaining py3- ports from
the tree, not adding more, but in this case I'm not sure there's a
better short term solution to address the missing functionality out of
the box.

> BTW, a thing surprises me is that we don't have a pkg-message which
> hints users to install separated standard Python modules since
> python34.  Does anybody knows why?  I haven't touched lang/pytohn* for
> a while.  I also found that python34 is directly added, not through
> `svn cp` from python33 (well, python33 itself is also not...)

If the pkg-message is inconsistent now, I'll fix it. Note this only
solves the problem for ports users, not package users.

python34 was directly added because it was built from scratch, leaving
as much if not all of the old legacy behind.

The initial commit log has more detail:

https://svnweb.freebsd.org/ports?view=revision&revision=350610

> And, for the python-version-specified ports, I found now we have:
> 
> devel/py-setuptools
> devel/py-setuptools27
> devel/py-setuptools32
> devel/py-setuptools33
> devel/py-setuptools34
> devel/py-setuptools35
> 
> These give us following packages:
> 
> py27-setuptools-17.0
> py27-setuptools27-17.0
> py32-setuptools32-17.0
> py33-setuptools33-17.0
> py34-setuptools34-17.0
> py35-setuptools35-17.0
> 
> I remember in the past, we add python-version-specified port using
> pyXY-foo format.  For example, we have

See original commit and the issue it resolved:

https://svnweb.freebsd.org/ports?view=revision&revision=347268
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187091

It's not pretty, but it's (still, I believe) needed, at least for now.

> devel/py-dbus
> devel/py3-dbus
> 
> in ports, which generate
> 
> py27-dbus-1.2.0_1
> py34-dbus-1.2.0_1
> 
> packages, so I think that the version suffix in port name is not
> really needed.  Or will trimming that make some other conflicts?
> 
> Any idea?
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5647F63B.6000303>