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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Jason Liu
If that is actually what is being done in this thread (I think it is, but I can't tell for sure), to perl5.28 and python38, let's make that clear.

But my question was, is that declaration simply a consensus among humans to simply put port:perl5.28 and port:python38 in the portfiles? Or is there some way to programmatically reference a ${global_default_python_version} variable in the portfiles, so that we don't have to go around changing hundreds of portfiles from port:python38 to port:python39? According to Ryan's earlier response to me:

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
 
it sounds like it might have to be the former?

-- 
Jason


On Tue, Jun 23, 2020 at 8:36 AM Ken Cunningham <[hidden email]> wrote:


On Jun 23, 2020, at 00:48, Ryan Schmidt <[hidden email]> wrote:

>> Feel free to set the bar, if you care to. And hopefully, don’t move it too often…IMHO.
>
> I'm not sure what you mean.

Exactly what I stated with...

If MP would pick one perl and one python that everyone is meant to use, declare it, and don't change it too often, that would be a Good Thing.

If that is actually what is being done in this thread (I think it is, but I can't tell for sure), to perl5.28 and python38, let's make that clear.

I'll go sort out what added perl5.30 to curl's build deps and revert it.

And everyone might stop randomly changing ports to use perl 5.30 or defaulting to some other python until some year in the moderately distant future.

Less work, less bloat, more happiness -- it's just a win all around.

And if that is impossible, unacceptable, or undesirable, then so be it. At least we tried...

K
Reply | Threaded
Open this post in threaded view
|

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

Jason Liu
In reply to this post by Mojca Miklavec-2
On Tue, Jun 23, 2020 at 1:06 AM Mojca Miklavec <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Daniel J. Luke
In reply to this post by ryandesign2
On Jun 22, 2020, at 11:20 PM, Ryan Schmidt <[hidden email]> wrote:
> On Jun 22, 2020, at 14:34, Daniel J. Luke wrote:
>> We should just have one perl5 port that tracks the current release.
>
> You say this every year (or at least often).

I say this every time we run into the set of problems that we would solve by moving to this method (that we continually avoid solving just kicking the can down the road with the current solution - which is a huge amount of work that we just have to repeat every time there's a perl release).

> Are you volunteering to be the one to ensure that every port that uses perl is compatible with the new perl release when it comes out? Without someone to do that, blindly upgrading everything from say perl 5.28 to 5.30 will likely break ports.

Every time we upgrade a library we 'blindly break ports' since we don't (and can't) comprehensively test every combination of things.

It sounds like your argument against doing this is "we want the ports tree to be stable" which I don't think has been the case in the past (and if we /do/ want it to be a stable tree, we shouldn't be doing may of the updates that we do now).

> Do you remember perl 5.26? It broke a lot of ports, requiring a lot of fixes like this to be added: https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe

I do, part of the pain with perl5.26 was that we waited a long time to update things because everyone was afraid of fixing the things that were broken.

I'll note that upstream already does test CPAN modules with new versions of perl (and notifies their version of maintainers) - so the things that remain broken are things that aren't actively maintained upstream (and if they remain broken in our ports tree, aren't being actively maintained by us either).

> The strategy currently being employed by those volunteers who are maintaining the perl ports is to keep everything defaulted to 5.28 for now, add 5.30 ports and fix problems in them as they're found, and once everything is building then switch the default to 5.30. This seems sensible to me.

Things get fixed faster when they're broken, I'd bet perl 7 (which is what perl5.32 is going to be) will be out before we're moved to perl5.30 (of course, perl 7 is going to break some backwards compatibility). I suspect the fundamental disagreement here is that I'm more comfortable with breaking things in the ports tree (and then fixing them) than you are.

--
Daniel J. Luke

Reply | Threaded
Open this post in threaded view
|

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

Ken Cunningham

On 2020-06-27, at 6:27 AM, Daniel J. Luke wrote:

> On Jun 22, 2020, at 11:20 PM, Ryan Schmidt <[hidden email]> wrote:
>> On Jun 22, 2020, at 14:34, Daniel J. Luke wrote:
>>> We should just have one perl5 port that tracks the current release.
>>
>> You say this every year (or at least often).
>
> I say this every time we run into the set of problems that we would solve by moving to this method (that we continually avoid solving just kicking the can down the road with the current solution - which is a huge amount of work that we just have to repeat every time there's a perl release).
>
>> Are you volunteering to be the one to ensure that every port that uses perl is compatible with the new perl release when it comes out? Without someone to do that, blindly upgrading everything from say perl 5.28 to 5.30 will likely break ports.
>
> Every time we upgrade a library we 'blindly break ports' since we don't (and can't) comprehensively test every combination of things.
>
> It sounds like your argument against doing this is "we want the ports tree to be stable" which I don't think has been the case in the past (and if we /do/ want it to be a stable tree, we shouldn't be doing may of the updates that we do now).
>
>> Do you remember perl 5.26? It broke a lot of ports, requiring a lot of fixes like this to be added: https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe
>
> I do, part of the pain with perl5.26 was that we waited a long time to update things because everyone was afraid of fixing the things that were broken.
>
> I'll note that upstream already does test CPAN modules with new versions of perl (and notifies their version of maintainers) - so the things that remain broken are things that aren't actively maintained upstream (and if they remain broken in our ports tree, aren't being actively maintained by us either).
>
>> The strategy currently being employed by those volunteers who are maintaining the perl ports is to keep everything defaulted to 5.28 for now, add 5.30 ports and fix problems in them as they're found, and once everything is building then switch the default to 5.30. This seems sensible to me.
>
> Things get fixed faster when they're broken, I'd bet perl 7 (which is what perl5.32 is going to be) will be out before we're moved to perl5.30 (of course, perl 7 is going to break some backwards compatibility). I suspect the fundamental disagreement here is that I'm more comfortable with breaking things in the ports tree (and then fixing them) than you are.
>
> --
> Daniel J. Luke
>


So in the end, are we setting texinfo back to perl5.28 ?

K
Reply | Threaded
Open this post in threaded view
|

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

Ken Cunningham
In reply to this post by ryandesign2


> On Jun 23, 2020, at 12:48 AM, Ryan Schmidt <[hidden email]> wrote:
>
> My ports are slightly out of date but I don't see a choking amount of dependencies for curl on High Sierra:
>
> $ port rdeps curl
> The following ports are dependencies of curl @7.70.0_0+ssl:
>  xz
>    lbzip2
>    libiconv
>      gperf
>    gettext
>      ncurses
>  pkgconfig
>  libidn2
>    autoconf
>    automake
>    libtool
>      xattr
>        unzip
>    libunistring
>      perl5
>        perl5.28
>          db48
>          gdbm
>            readline
>      texinfo
>        help2man
>          p5.28-locale-gettext
>        perl5.30
>  libpsl
>    python38
>      bzip2
>      expat
>      libedit
>      libffi
>      openssl
>        zlib
>      sqlite3
>      python_select
>      python3_select
>    glib2
>      libxml2
>        icu
>      pcre
>  curl-ca-bundle
>
>
> If you are on an older system you may have additional dependencies in the chain, likely compilers, but that's not curl's fault; it doesn't impose any compiler restrictions. Its dependencies might.
>


some trimming of the curl portfile, removing the deps on libidn and libpsl (which macports-base does not appear to need in curl to run), and thanks for to you for removing perl from curl-ca-bundle recently, and I now have a very lean built-from-os-roots curl sufficient to support macports-base and many other purposes down to this most set of ports, even on older systems:

$ sudo port -v install curl
--->  Computing dependencies for curl......
The following dependencies will be installed:
 curl-ca-bundle
 gperf
 libiconv
 openssl
 pkgconfig


pkgconfig calls in gperf and libiconv, otherwise it’s just openssl and curl/curl-ca-bundle. I suppose I could even do without pkgconfig as well, and just pass in the paths, but that’s lean enough for now. No perls, no pythons.

I’ll call it skip-the-dishes-curl or something ...

Ken




12