upt-macports project update and feedback request

[Ryan Schmidt]

On Jun 5, 2019, at 21:36, Karan Sheth wrote:

> 1. The naming convention of Python ports
> For upt to be able to process dependencies correctly and add missing packages recursively, it is important to have a consistent naming scheme for ports. Currently, that is not completely the case, although most ports follow “py-<PyPI/upstream>”. In some cases though we keep the capitalization, for some others we convert it to all lowercase; additionally, some ports do not follow this convention (e.g., py-dateutil, where PyPI is “python-dateutil” or “py-codestyle”, where PyPI is “pycodestyle”).
> 
> Our proposal is to use “py-<upstream.lowercase()>” for all Python ports going forward and renaming the ones that currently do not follow this convention. Are there any concerns, objections, and/or considerations here we might have missed? In any case, we will need to do some renaming to get everything consistent (irrespective of what convention we choose), but it will help for maintainability in the long run.

Originally it was up to the maintainer's discretion how to name Python module ports, and especially "py" prefixes on upstream names were often removed, since it was seen to be redundant with the required "py-" port name prefix. But then there was an effort some years ago to begin to rename Python module ports to more closely match upstream. For example here py-svn was renamed to py-pysvn:

https://github.com/macports/macports-ports/commit/b10950c24d9b759c2efbc816476fc093c69ed031

Continuing that task and renaming any other ports we missed is probably a good idea.

Originally, all-lowercase port names were encouraged, because users often specify port names in all lowercase and there were a few bugs in MacPorts when the capitalization specified did not match the capitalization used in the port. But those bugs have been fixed for years so all-lowercase names should no longer be preferred, and using upstream capitalization probably makes sense.

But I agree with Joshua that a means of accommodating name deviations is probably necessary. Presumably the upstream project name can be found somewhere in each Portfile, such as in the master_sites. Maybe that information can be used instead of the port name.

Or maybe there should be a python portgroup variable for specifying the upstream name, and then you could use that instead of the name. I think python.rootname was meant to be that, but if so, I don't think all portfile maintainers were aware of that; for example some portfiles specify master_sites manually, without basing it on python.rootname.