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
