Version specific ports of "unpackaged" Python standard library modules

[lwhsu]

Summary

Add version specified ports of separated standard Python modules for
non-default Python versions:

• Add pyXY-{sqlite3,gdbm,tkinter} ports for generating binary packages
• Improve/add pkg-message to point users to install respective packages of separated Python standard modules
• Add COMMENT to explicitly show the Python version that package should be used with
• Simplify version-related PYTHON_* for lang/python35

databases/py32-gdbm
databases/py33-gdbm
databases/py34-gdbm
databases/py35-gdbm
databases/py32-sqlite3
databases/py33-sqlite3
databases/py34-sqlite3
databases/py35-sqlite3
x11-toolkits/py32-tkinter
x11-toolkits/py33-tkinter
x11-toolkits/py34-tkinter
x11-toolkits/py35-tkinter

[lwhsu]

Weird, these Makefile's should not be empty

[lwhsu]

Hmm, I just don't know why the added Makefile's are shown as empty in phabricator...
I put my patch here first: https://people.freebsd.org/~lwhsu/patch/python-standard-ports.diff
I'll ask what's going on.

[koobs]

@lwhsu There's a bug in arc(8) client where the contents are not uploaded for newly created files (cc @eadler x 5)

Workaround: svn diff > patch the path, then click "Update Diff" inside this review to manually update it

[lwhsu]

Manually upload the diff.

[koobs]

Should we be customising pkg-message's for the respective lang/pythonXY port to point directly to these suffixed-versions?

How else will a user know where/how to find them, instead of just attempting to install the suffix-less version?

[lwhsu]

In D4170#88336, @koobs wrote:

Should we be customising pkg-message's for the respective lang/pythonXY port to point directly to these suffixed-versions?

Makes sense, and we have discussed about adding pkg-message for lang/python{33,34}

How else will a user know where/how to find them, instead of just attempting to install the suffix-less version?

And perhaps I can also update this patch to make COMMENT include version, like lang/clang37.

[koobs]

Agreed, output on pkg info / version should be version specific (nice for concurrent installations)

[lwhsu]

In D4170#88316, @koobs wrote:

@lwhsu There's a bug in arc(8) client where the contents are not uploaded for newly created files (cc @eadler x 5)
Workaround: svn diff > patch the path, then click "Update Diff" inside this review to manually update it

BTW, @koobs, are you sure the issue is in arc itself?

[koobs]

In D4170#88363, @lwhsu wrote:

In D4170#88316, @koobs wrote:

@lwhsu There's a bug in arc(8) client where the contents are not uploaded for newly created files (cc @eadler x 5)
Workaround: svn diff > patch the path, then click "Update Diff" inside this review to manually update it

BTW, @koobs, are you sure the issue is in arc itself?

I am not :)

[koobs]

• I'd remove "for " from COMMENT
• Replace hard coded pyxy in pkg-message with SUB_FILES (make future repocopies safer, reduce diffs)

[lwhsu]

In D4170#88374, @koobs wrote:

• I'd remove "for " from COMMENT

Done.

• Replace hard coded pyxy in pkg-message with SUB_FILES (make future repocopies safer, reduce diffs)

Done, I should think one more second. :)

BTW, why does lang/python35 use DISTVERSION instead of PORTVERSION?

[koobs]

In D4170#88389, @lwhsu wrote:

BTW, why does lang/python35 use DISTVERSION instead of PORTVERSION?

It was committed while it was 3.5.0rc3 :)

[koobs]

Other than PYTHON_SUFFIX=${PORTVERSION:R:S/.g}// (isn't PYTHON_SUFFIX already defined/available via python.mk) the changes look good

I'm assuming you've QA'd (poudriere) the ports to confirm that pass checks (I cant see it in the TEST PLAN section)

Edit: Will wait for your reply to this comment before I accept/request changes

lang/python32/Makefile

34 ↗

(On Diff #10298)

Isn't PYTHON_SUFFIX already set by python.mk ?

www/py-gunicorn] make -V PYTHON_SUFFIX
27

[lwhsu]

lang/python32/Makefile

34 ↗

(On Diff #10298)

Yes, but lang/python* doesn't include python.mk:

lang/python32 > make -V PYTHON_SUFFIX

[lwhsu]

• Replace DISTVERSION with PORTVERSION for lang/python35

[lwhsu]

In D4170#88391, @koobs wrote:

Other than PYTHON_SUFFIX=${PORTVERSION:R:S/.g}// (isn't PYTHON_SUFFIX already defined/available via python.mk) the changes look good

lang/python* doesn't include python.mk, so that's needed.

OTOH, lang/python35 duplicates itself, so I just use it.

I'm assuming you've QA'd (poudriere) the ports to confirm that pass checks (I cant see it in the TEST PLAN section)

Yes I'm running the final testing, I'll commit that after confirm it passed.

Edit: Will wait for your reply to this comment before I accept/request changes

[koobs]

This comment has been deleted.

lang/python35/Makefile

8–30 ↗

(On Diff #10299)

These variables should be safe for all/any future values of PORTVERSION or DISTVERSION (with or without alpha/beta/rcX suffixed).

I believe that's why I set them to DISTVERSION, since DISTVERSION is always calculated (and the same as PORTVERSION, if set)

[lwhsu]

Summaries of the changes:

• Add pyXY-{sqlite3,gdbm,tkinter} ports for generating binary packages
• Improve/add pkg-message to point users to install respective packages of separated Python standard modules
• Add COMMENT to explicitly show the Python version that package should be used with
• Replace DISTVERSION with PORTVERSION for lang/python35

[lwhsu]

lwhsu@lwbsd:~/ports/lang/python35 > make -V PYTHON_PORTVERSION
3.5.0
lwhsu@lwbsd:~/ports/lang/python35 > make -V PYTHON_VER
3.5
lwhsu@lwbsd:~/ports/lang/python35 > make -V PYTHON_VERSION
python3.5
lwhsu@lwbsd:~/ports/lang/python35 > make -V PYTHON_SUFFIX
35
lwhsu@lwbsd:~/ports/lang/python35 > make -V PKGNAME
python35-3.5.0_1

[lwhsu]

After discussing on IRC, latest change makes sense now.

[koobs]

LGTM!