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.
