Suggestion to slightly simplify pypi ports

Ryan Schmidt ryandesign at macports.org
Sun Jun 23 08:46:58 UTC 2019



On Jun 23, 2019, at 02:52, Mojca Miklavec wrote:

> I would like to suggest providing simplification for the following four lines:
> 
> name                py-foo
> version             1.2.3
> master_sites        pypi:[string index ${python.rootname} 0]/${python.rootname}
> distname            ${python.rootname}-${version}
> 
> which could read like the following, for example to set all four lines:
> 
> pypi.setup          foo 2.3.1
> 
> but we would need to also provide support for:
> - cases when "py-foo" isn't pointing to pypi package "foo" (different rootname)
> - regular ports outside of python subdir
> - proper support when we want to use subports with different packages
>  (let's say that we would want to put [py-]buildbot,
> [py-]buildbot-console-view, [py-]buildbot-grid-view,
> [py-]buildbot-waterfall-view in the same port and create subports with
> equally trivial syntax and minimal overhead).
> 
> Since Karan is actively working on a tool to create pypi-based ports
> it would be nice to come up with suitable portgroup modifications
> soon, so that the results can be simplified and so that there will be
> less ports to change later.
> 
> Any thoughts?

I agree it would be good to get this repetitive code out of python portfiles.

But at some point we decided that setup procedures were an antipattern, especially the fact that they set the port name and version, since that makes it more difficult to use more than one portgroup in a single portfile. (Which portgroup's setup procedure sets the name and version? Are all portgroups' setup procedures engineered to accommodate this situation?) It is also clearer for the portfile author if the name and version are set the usual way, by setting the name and version options (or setting the name using a subport block, since you bring up the topic of subports). The python-1.0 portgroup deliberately doesn't have a setup procedure and I don't think we should add one. The php-1.0 portgroup did have a setup procedure but the php-1.1 portgroup doesn't have one; removing the setup procedure was one of my design goals for the php-1.1 portgroup.

The php-1.1 portgroup accommodates the very common situation of a php extension hosted at pecl by offering a php.pecl option that can be set to yes to set up values for master_sites, livecheck and so forth that are common to that situation. The php-1.1 portgroup takes the name of the pecl module from the port name, with a php.rootname option the portfile can use to override it if necessary. Similarly, the python-1.0 portgroup could offer a python.pypi or simply just pypi option which a port could set to yes to set up the common values, and it already has a python.rootname option for overriding the module name inferred from the port name.



More information about the macports-dev mailing list