<div dir="ltr"><div dir="ltr"><div>On Tue, Jun 23, 2020 at 1:06 AM Mojca Miklavec <<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a>> wrote: <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I would say that we happily accept a pull request that "just bumps"<br>
all dependents of perl5[.x].<br>
Then all the ports will magically work with 5.30.<br>
<br>
I seriously mean that.</div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>On Mon, Jun 22, 2020 at 11:57 PM Ryan Schmidt <<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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.</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>...</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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. <br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 23, 2020 at 1:06 AM Mojca Miklavec <<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 22 Jun 2020 at 21:34, Daniel J. Luke wrote:<br>
><br>
> 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)<br>
<br>
I would say that we happily accept a pull request that "just bumps"<br>
all dependents of perl5[.x].<br>
Then all the ports will magically work with 5.30.<br>
<br>
I seriously mean that. In the past I've done some batch updates, but<br>
it's still hundreds of ports, and it's a non-trivial amount of work<br>
even if the individual updates are trivial. At least in the ports I<br>
touched I tried to ensure that the perl version is only mentioned once<br>
and the variable is being reused elsewhere, so you just need to<br>
replace 5.28 with 5.30, revbump and see if the ports stil builds (in<br>
most cases it does; there are some clusters of software that need to<br>
use the exact same version of perl at once).<br>
<br>
> OR some enhancement to base to make it so the revbump is unnecessary.<br>
<br>
That's not feasible. Unless the enhancement is to uninstall all ports<br>
and reinstall them from scratch.<br>
<br>
Mojca<br>
</blockquote></div>
</div>