upt-macports project update and feedback request

[Rainer Müller]

On 06.06.19 04:36, Karan Sheth via macports-dev wrote:
> Community feedback is requested on the following topics:
> 
> 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.

How would you identify existing ports that need a rename?

Keep in mind that a rename that only changes the port directory name to
lowercase might be a bit tricky as the filesystem is usually
case-insensitive.

> 2. Packaging of Ruby ports
> There is an “upt-rubygems” frontend in upt that we can leverage to
> generate Ruby portfiles and we are currently looking into this. As many
> of the current Ruby ports are outdated and are supporting EOL versions
> of Ruby, my mentor @reneeotten suggested the following: 
> "Disclaimer: I am not very familiar with Ruby and only spend an hour or
> so looking through the PortGroup and some of the ports; so this is by no
> means fully worked out, but it seems to me that the PortGroup could use
> some attention to start with. I’d suggest updating the current PortGroup
> (or probably better to add a new one as ruby-1.1.tcl) in which we add
> support for the most recent Ruby version (2.6) and ideally drop support
> for EOLed versions, including the 1.x branch."
> 
> Any feedback from MacPorts/Ruby users at this time on both the proposal
> to drop older versions and things to consider for the PortGroup or Ruby
> packaging, in general, would be highly appreciated.

Adding Wataru Kimura to CC as maintainer of our ruby* ports and also
lots of modules. What is your take on getting rid of old ruby versions?

Going for a ruby-1.1.tcl sounds like a reasonable way to get incremental
steps that avoid too much interference with the existing rb-* ports.
> Finally, if you’re interested in this GSoC project, please take a look
> at the repository (https://github.com/macports/upt-macports) or install
> the “py37-upt” port and give it a try. The template for PyPI/Python
> ports is complete, the templates for CPAN/Perl and RubyGems/Ruby are
> fairly complete, but we’re still working out some details. Feedback from
> the community is very welcome!

I would recommend to rename this port to "upt" and install the binary
without suffix. As a user, I do not care which version of python the
tool uses or that it is even written in Python at all. I just want to
run the "upt" executable.

I am aware this comes up a lot lately, but I think the distinction
between tools and modules is important. I would never expect a py-*
prefix on ports such as meld, diffoscope, or bzr.

Rainer