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

[Jason Liu]

On Tue, Jun 23, 2020 at 1:06 AM Mojca Miklavec <mojca at macports.org> wrote:

> I would say that we happily accept a pull request that "just bumps"
> all dependents of perl5[.x].
> Then all the ports will magically work with 5.30.
>
> I seriously mean that.
>

I would tend to say that this is now also more true for python than in the
past. I don't really deal very much with php, so I can't really comment
there.

On Mon, Jun 22, 2020 at 11:57 PM Ryan Schmidt <ryandesign at macports.org>
wrote:

> 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.
>
...
>
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.
>

In the past, this was indeed the case. Around 10 years ago, NumPy and SciPy
were notorious examples of this, where even upgrading from one minor patch
version to another could break lots of software that used these nearly
ubiquitous modules, and often resulted in dependency hell. This meant that
software authors had to declare things like "This software depends on SciPy
1.2.14" in their READMEs. Nowadays, most of the software that I've been
packaging for MacPorts simply say "This software depends on <python
module>" without even bothering to specify a minimum/maximum compatible
version.

This seems to indicate that most of the popular python modules have
stabilized to a point that is closer to what Mojca describes for perl, at
least from my own anecdotal testing. When I write a portfile, if the
project author only says that python or a python module is required, and
doesn't specify any version number, then I usually test out my portfile by
at least trying out python38, python37, and python36 for my local builds,
before I submit a PR. I have yet to run into a case recently where a
portfile builds with a py38- module, but it fails with the py36- version of
the module. Again, I admit that this is completely anecdotal and only based
on my own experience.

-- 
Jason Liu


On Tue, Jun 23, 2020 at 1:06 AM Mojca Miklavec <mojca at macports.org> wrote:

> On Mon, 22 Jun 2020 at 21:34, Daniel J. Luke wrote:
> >
> > 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)
>
> I would say that we happily accept a pull request that "just bumps"
> all dependents of perl5[.x].
> Then all the ports will magically work with 5.30.
>
> I seriously mean that. In the past I've done some batch updates, but
> it's still hundreds of ports, and it's a non-trivial amount of work
> even if the individual updates are trivial. At least in the ports I
> touched I tried to ensure that the perl version is only mentioned once
> and the variable is being reused elsewhere, so you just need to
> replace 5.28 with 5.30, revbump and see if the ports stil builds (in
> most cases it does; there are some clusters of software that need to
> use the exact same version of perl at once).
>
> > OR some enhancement to base to make it so the revbump is unnecessary.
>
> That's not feasible. Unless the enhancement is to uninstall all ports
> and reinstall them from scratch.
>
> Mojca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200623/8db01786/attachment-0001.htm>