Version specified ports for separated standard Python modules

[Li-Wen Hsu]

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 at .
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.

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...)

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

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?

-- 
Li-Wen Hsu
http://lwhsu.org