Prefix and suffix for Python ports
With the upcoming changes to the ports infrastructure that will allow us to create packages for different python versions from a single physical port, we need to make sure that those packages are properly named to avoid package naming conflicts.
If a port is being built for Python 2.7 (installs data to directories owned by that python installation, such as lib/python2.7/site-packages), it should be named in a way that clearly identifies its relation to Python 2.7. For that purpose PYTHON_PKGNAMEPREFIX exists in bsd.python.mk.
Using PYTHON_PKGNAMEPREFIX for the port
PORTNAME= foo
PORTVERSION= 1.0
CATEGORIES= devel
PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
...
will result in the package
py27-foo-1.0.tbz
Likewise, without changes to the port Makefile, a package targeting Python 3.3 will be named
py33-foo-1.0.tbz
The internal package name (PKGNAME) will be set to a combination of PKGNAMEPREFIX, PORTNAME and PKGNAMESUFFFIX, resulting in
py27-foo (for Python 2.7)
and
py33-foo (for Python 3.3)
PYTHON_PKGNAMEPREFIX shall be used for ports that can be installed for different python versions1. And there is PYTHON_PKGNAMESUFFIX, which was introduced in revision 91400. Around ten years ago, it might have sounded like a good idea that ports, which do not follow a common py<NAME> scheme (upstream or in the ports tree) will receive a suffix to their package name, because people would rather look for foo than for py-foo. That was the reason for PYTHON_PKGNAMESUFFIX.
Using the suffix, applied to the example from above will result in the following names:
foo-py27 (for Python 2.7) foo-py33 (for Python 3.3)
Prefix? Suffix? Both?
So, how do both, the prefix and suffix influence our ports and packages?
Let's take a closer look at the ports tree. Many python-related ports (modules) follow a py-<NAME> naming scheme within the tree. The prefix clearly identifies the port as dependent on the Python language, but there's not much more to that. We had some discussion about the prefix recently on IRC and, while I'm positive about the prefix and support it, I also can see that it is ridiculous to enforce it (if there are no naming conflicts).
Pythonistas will search for the python module foo or PyFoo or whatever its name is on PyPi, when they first encounter the FreeBSD ports system or package search mechanisms. It is very unlikely that they grasp the (historical) naming scheme, we are following at the moment. Even worse, it can become utterly confusing for python modules, which have a py at the beginning of their name, such as Pygame.
If we'd strictly follow our traditional naming scheme, Joe Pythonista would now search for something like
py-pygame
Oddly enough, our (port maintainer) habit often is to strip the leading py of the name, since we prefix it with py-. See, where this leads too? Right:
py-game
No one, who's not familiar with those quirks, would search for py-game. Would you? With the PYTHON_PKGNAMEPREFIX, the package name will add some more confusion:
py27-game
Luckily, the advice to search for ports is to use
# make search name=<name> # make search key=<keyword>
Users can search for the name, so they should be able to find the port via its official upstream name, right? No, since the rule of thumb is to strip the py prefix from the PORTNAME.
What now?
The prefix and suffix for packages should not bring us into a situation, where even more inconsistencies are added. Using a prefix and suffix, depending on quite vague rules, together with modified names of the upstream project, won't help people.
In my opinion, the PORTNAME for python ports should match the name of the original upstream project to allow users to quickly find what they are looking for. Having prefixes and suffixes at the same time should be prevented. Instead, PYTHON_PKGNAMESUFFIX should be removed completely and, to allow consistency throughout the package naming scheme, only PYTHON_PKGNAMEPREFIX should be kept. This also would simplify 3rd party tools that operate on packages, search & find operations and similar usage scenarios.
| [1] | http://www.freebsd.org/doc/en/books/porters-handbook/using-python.html |