randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

[Ryan Schmidt]

On Jun 22, 2020, at 22:26, Jason Liu wrote:

>> We should just have one perl5 port that tracks the current release. We'd just need to either revbump everything that needs a rebuild when a new minor perl version comes out (all the p5- ports to start) OR some enhancement to base to make it so the revbump is unnecessary.
>>  
>> It might be an idea for the admins to "set" the perl version all ports will use (barring some actual real need for another), and then --- all-at-once -- change it to some new version to avoid this.
> 
> I think python might be another compiler/interpreter which could benefit from such a system.
> 
> Either going with Dan's method of having a one python3 port that tracks the current release, and a corresponding set of py3-* ports that track the python3 port.

For perl, I can understand Daniel's point somewhat since perl is a very old language and not a lot changes from release to release. There is a high likelihood that a module compatible with one version of perl will be compatible with the next newer version, although perl5.26 was a notable recent exception.

But for python, I would strongly oppose this. It seems like a lot more things change in each new python release, with a likelihood that modules will be broken or need updates to be compatible. It's not feasible for any one maintainer to update a hypothetical python3 port to a new major version and verify that all py3-* modules are compatible with it. And without such verification, just blindly committing an update, it falls to users to experience the breakage and report it to us. This degrades the user experience.

Our current strategy ensures things continue to work for users. If we add python38, that doesn't impact users using python37. If the user uses a module that's not yet compatible with python38, that's fine; they can stay on python37 until that gets fixed. Each module can be fixed at its own pace.

My thoughts for php are the same as those for python.


> Or, going with Ken's method and "setting" the default python version that all ports will use.

If you mean that users should have a way to set such a default python version, that's what variants are for. We have standardized the variant names that ports should use for providing functionality for a python version (e.g. the +python38 variant for python 3.8 support). This way, users can put +python38 into their variants.conf if they want that variant to be chosen for any ports that offer it. If we want to enhance the user experience of this functionality, we would need to add python variants to the ports that currently specify only a single version. This is extra and sometimes nontrivial work for the maintainer to do initially to set those variants up, and it's more work going forward as the maintainer needs to test each update of the port with each version of python (or likely forget to do so, eventually resulting in a problem for users who aren't using the default, which they then have to report to us, which is a bad user experience).

It's also more work for the user if the default variant changes and they want to switch to the new default. That's https://trac.macports.org/ticket/46956

If you mean that MacPorts management should state that a particular version of python shall be used by all ports, I think we've already stated that it shall be python38 or whatever is specified as the default in the python 1.0 portgroup (and that should be the latest stable version of python, although it is acceptable if it is not updated immediately after the release of a new version of python to accommodate testing and resolving some initial issues with the new version). The problem is there is no enforcement mechanism and it is up to each portfile maintainer to ensure that their ports do this. There is no good way to just magically make all ports that use python use a different version. Each port needs to be modified by hand and tested to ensure it still works with that change.

MacPorts is a volunteer project. There are a zillion opportunities for people to contribute. One way is to identify ports that depend on older python versions, update them to use newer versions and verify they still work, and submit a PR.

If you mean that MacPorts base or an include file in the ports tree should define a variable for the currently accepted perl or python version and ports should use this variable in declaring their dependencies and so forth, that's been suggested before but is not possible with how MacPorts base currently works with regard to the portindex. See https://trac.macports.org/ticket/59839


> Either of those methods could help to reduce or eliminate what's happening right now in lots of portfiles, where the portfile author basically has to arbitrarily pick a version of python to use as the portfile's default.

Nothing should be arbitrary. If only a single version of python is chosen for a port, it should be the one that's set as the default in the python 1.0 portgroup.