Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On Jan 21, 2022, at 19:43, Gabriel Rosenkoetter wrote: > I'm… also not sure it's even actually a good idea, since, in my experience, > Perl is much more flexible about newer versions of `perl` functioning with > "out-dated" versions of libraries *and* vice versa than, say, PHP is. (I > think maybe Python plays better with date-of-release mismatches?) I agree that it does seem that perl versions are typically more backward-compatible than some other software. Perl is very mature software that probably doesn't need to introduce many breaking changes at this point (though there was at least one notable exception in recent memory where "." was removed from the default inc path which broke a zillion modules which then had to be patched). For this reason, and because of the complexity that comes with having multiple perl versions, it has often been suggested that MacPorts should abandon offering multiple perl versions and should just offer one -- the latest. Transitioning MacPorts to just one perl would be a large undertaking, so we should probably be sure that we want to do that before anyone puts in the effort to do it. We did, after all, used to have just one perl and a long time ago switched to offering multiple perls, because at the time we thought that was a good thing to do.
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On Jan 21, 2022, at 22:48, Kastus Shchuka wrote: > This is for example what I have: > > $ port installed and perl5 port installed perl5 "installed" is the command, "perl5" is the list of ports the command will operate on. > The following ports are currently installed: > perl5 @5.26.1_0+perl5_28 > perl5 @5.28.3_0+perl5_28 > perl5 @5.28.3_0+perl5_30 (active) > > If you want to see just the active port, you may trim down the output like > this: > > $ port installed and active and perl5 port installed active and perl5 > The following ports are currently installed: > perl5 @5.28.3_0+perl5_30 (active)
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On Jan 21, 2022, at 23:32, Gabriel Rosenkoetter wrote: > > I think the [+] label, in the output of `port info ` is a confusing > UI/UX choice, especially in the context of the + as an argument to `port > install +_version` to request activation of a specific Port > version. > > I think displaying the default/anticipated version makes a lot of sense, I'm > just saying the way that's expressed (and that the currently "active" version > isn't expressed at all in *that* output) is confusing. > > That is: I think using + both to say "install this version" and "regardless > of what's active, our default would've been this" is a confusing conflation > of symbols. > > Maybe `port info …` should use another symbol (*?) there, and should display > the active version by bracketing the version name? The use of the "+" character is intentional. "+" means a variant is enabled. "-" means a variant is disabled. "[ ]" around either "+" or "-" means the choice comes from the port's default_variants directives. "( )" around either "+" or "-" means the choice comes from your variants.conf file. No symbol around "+" or "-" means the choice comes from what you specified on the command line. This is explained in the port-variants manpage. > I'm confused about why that'd read "perl5 @5.28.3 (lang)" rather than "perl5 > @5.34.0 (lang)" on the system in question. The version field of the perl5 port is 5.28.3, regardless what variant is chosen. It is not permitted for a port to change its version (or revision or epoch) in a variant; the portindex does not accommodate that. The version field of the perl5 port is pretty irrelevant since the port does nothing other than depend on other ports that install the real files. The version of the perl5 port could just as easily have been "1.0" or "0" or "42".
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On Jan 22, 2022, at 00:28, Kastus Shchuka wrote:
>
> Please note a clash of terms as there is port action "installed" and port
> pseudo-portname "installed". That is why "port installed" is a valid syntax
> ("installed" is an action here), while "port active" is not. You have to use
> action "echo" with "active", like "port echo active".
You can use any action you want; it doesn't have to be echo. For example,
typically you might want "port installed active".
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On Jan 22, 2022, at 01:15, Gabriel Rosenkoetter wrote: > > On 2022-01-22 01:28 EST, Kastus Shchuka wrote: >> $ port echo installed and perl5 >> perl5 @5.26.1_0+perl5_28 >> perl5 @5.28.3_0+perl5_28 >> perl5 @5.28.3_0+perl5_30 > > You see how this is at best confusing and at worst user-antagonistic, right? I'm sorry you feel antagonized; I'm sure that was nobody's intention. This is one of the aforementioned challenges/complexities with providing multiple versions of a port. If we stick with multiple perl versions, and the perl5 port to create the symlinks, then maybe it would indeed help reduce some confusion to change the perl5 port's version to 1.0, or a MMDD date, or anything else that is not the version of one of the perl ports.
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On 2022-01-22 09:10 EST, Ryan Schmidt wrote: The use of the "+" character is intentional. "+" means a variant is enabled. "-" means a variant is disabled. "[ ]" around either "+" or "-" means the choice comes from the port's default_variants directives. "( )" around either "+" or "-" means the choice comes from your variants.conf file. No symbol around "+" or "-" means the choice comes from what you specified on the command line. This is explained in the port-variants manpage. Huh. Okay. That's helpful, thank you! I still think it's confusing for the output of, eg, `port variants perl5`, to place a special marker on the default version of the port, but to not indicate what version the user will get when they run, eg, `/opt/local/bin/perl`. I understand that that data isn't necessarily available in the portindex. I'm saying maybe it should be? The version field of the perl5 port is pretty irrelevant since the port does nothing other than depend on other ports that install the real files. The version of the perl5 port could just as easily have been "1.0" or "0" or "42". Gotcha. I think I agree that synchronizing that to the implied version of Perl is probably less confusing than generating a separate numberspace. -- Gabriel Rosenkoetter (he/him) g...@eclipsed.net OpenPGP_signature Description: OpenPGP digital signature
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On 2022-01-22 09:14 EST, Ryan Schmidt wrote: On Jan 22, 2022, at 01:15, Gabriel Rosenkoetter wrote: On 2022-01-22 01:28 EST, Kastus Shchuka wrote: $ port echo installed and perl5 perl5 @5.26.1_0+perl5_28 perl5 @5.28.3_0+perl5_28 perl5 @5.28.3_0+perl5_30 You see how this is at best confusing and at worst user-antagonistic, right? I'm sorry you feel antagonized; I'm sure that was nobody's intention. Wait, wait, I take the antagonistic part of that back, in light of your other response: On 2022-01-22 09:11 EST, Ryan Schmidt wrote: > You can use any action you want; it doesn't have to be echo. For example, typically you might want "port installed active". This is the output I was looking for: [15] (gr@wedge:~)% port installed active and perl5 The following ports are currently installed: perl5 @5.28.3_0+perl5_34 (active) [16] (gr@wedge:~)% That is, it shows the perl5 port version as well as the "what Perl will I get if I run `perl`" version. After this discussion, I understand clearly which version means what in there, and I see how the query language has been designed to be at least a little friendly to the non-programmer. (I think this is probably still a pretty steep learning curve for a new user, but I don't have any better suggestions.) This is one of the aforementioned challenges/complexities with providing multiple versions of a port. Heard. If we stick with multiple perl versions, and the perl5 port to create the symlinks, then maybe it would indeed help reduce some confusion to change the perl5 port's version to 1.0, or a MMDD date, or anything else that is not the version of one of the perl ports. I realize that I just sent an email stating the opposite, and I maintain that "1.0" is a bad idea (because it'll eventually climb to being confusingly similar with actual Perl version numbers), but using a POSIX date sounds very promising to me, and would avoid showing, as above, both "5.28.3" and (something that expands to:) "5.34.0" applied to the same port at the same time. -- Gabriel Rosenkoetter (he/him) g...@eclipsed.net OpenPGP_signature Description: OpenPGP digital signature
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On Jan 22, 2022, at 09:22, Gabriel Rosenkoetter wrote: >> If we stick with multiple perl versions, and the perl5 port to create the >> symlinks, then maybe it would indeed help reduce some confusion to change >> the perl5 port's version to 1.0, or a MMDD date, or anything else that >> is not the version of one of the perl ports. > > I realize that I just sent an email stating the opposite, and I maintain that > "1.0" is a bad idea (because it'll eventually climb to being confusingly > similar with actual Perl version numbers), There is precedent for using an arbitrary version 0.0 or 0.1 or 1.0; see for example our "select" ports: port info --name --version name:_select$ I wasn't necessarily suggesting that the version should start at 0 or 1 and be increased when the perl version changes. The version could stay at 0 or 1 forever, with just the revision increasing when needed. > but using a POSIX date sounds very promising to me, and would avoid showing, > as above, both "5.28.3" and (something that expands to:) "5.34.0" applied to > the same port at the same time. A date is what we use in several other ports when a version number is not readily available (such as a project that just commits changes to their repository and never releases stable versions) so there is precedent for this as well.
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
I have no idea of the difficulty of such a change, but it would be interesting if Portfiles contained a release date, and the database of installed ports had both a copy of that for any given installed version, and perhaps the date of installation. > On Jan 22, 2022, at 10:22, Gabriel Rosenkoetter wrote: > > On 2022-01-22 09:14 EST, Ryan Schmidt wrote: >> On Jan 22, 2022, at 01:15, Gabriel Rosenkoetter wrote: >>> On 2022-01-22 01:28 EST, Kastus Shchuka wrote: $ port echo installed and perl5 perl5 @5.26.1_0+perl5_28 perl5 @5.28.3_0+perl5_28 perl5 @5.28.3_0+perl5_30 >>> You see how this is at best confusing and at worst user-antagonistic, right? >> I'm sorry you feel antagonized; I'm sure that was nobody's intention. > > Wait, wait, I take the antagonistic part of that back, in light of your other > response: > > On 2022-01-22 09:11 EST, Ryan Schmidt wrote: > > You can use any action you want; it doesn't have to be echo. For example, > > typically you might want "port installed active". > > This is the output I was looking for: > > [15] (gr@wedge:~)% port installed active and perl5 > The following ports are currently installed: > perl5 @5.28.3_0+perl5_34 (active) > [16] (gr@wedge:~)% > > That is, it shows the perl5 port version as well as the "what Perl will I get > if I run `perl`" version. > > After this discussion, I understand clearly which version means what in > there, and I see how the query language has been designed to be at least a > little friendly to the non-programmer. > > (I think this is probably still a pretty steep learning curve for a new user, > but I don't have any better suggestions.) > >> This is one of the aforementioned challenges/complexities with providing >> multiple versions of a port. > > Heard. > >> If we stick with multiple perl versions, and the perl5 port to create the >> symlinks, then maybe it would indeed help reduce some confusion to change >> the perl5 port's version to 1.0, or a MMDD date, or anything else that >> is not the version of one of the perl ports. > > I realize that I just sent an email stating the opposite, and I maintain that > "1.0" is a bad idea (because it'll eventually climb to being confusingly > similar with actual Perl version numbers), but using a POSIX date sounds very > promising to me, and would avoid showing, as above, both "5.28.3" and > (something that expands to:) "5.34.0" applied to the same port at the same > time. > > -- > Gabriel Rosenkoetter (he/him) > g...@eclipsed.net -- eMail: mailto:rlha...@smart.net smime.p7s Description: S/MIME cryptographic signature
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On Jan 22, 2022, at 09:06, Gabriel Rosenkoetter wrote: > > On 2022-01-22 09:10 EST, Ryan Schmidt wrote: >> The use of the "+" character is intentional. >> "+" means a variant is enabled. "-" means a variant is disabled. >> "[ ]" around either "+" or "-" means the choice comes from the port's >> default_variants directives. "( )" around either "+" or "-" means the choice >> comes from your variants.conf file. No symbol around "+" or "-" means the >> choice comes from what you specified on the command line. This is explained >> in the port-variants manpage. > > Huh. Okay. That's helpful, thank you! > > I still think it's confusing for the output of, eg, `port variants perl5`, to > place a special marker on the default version of the port, but to not > indicate what version the user will get when they run, eg, > `/opt/local/bin/perl`. > > I understand that that data isn't necessarily available in the portindex. I'm > saying maybe it should be? > >> The version field of the perl5 port is pretty irrelevant since the port does >> nothing other than depend on other ports that install the real files. The >> version of the perl5 port could just as easily have been "1.0" or "0" or >> "42". > > Gotcha. I think I agree that synchronizing that to the implied version of > Perl is probably less confusing than generating a separate numberspace. It is not possible for a port to offer a different version based on what variant has been selected. If a port were to do that, the port would either not show up as outdated when "port outdated" or "sudo port upgrade outdated" are run, or else it would always show up as outdated even when it is not. The portindex, which is what is used to determine outdatedness, only stores one set of data for each port -- the data corresponding to whatever that port's default variants are.
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
On Jan 22, 2022, at 09:36, Richard L. Hamilton wrote: > I have no idea of the difficulty of such a change, but it would be > interesting if Portfiles contained a release date, and the database of > installed ports had both a copy of that for any given installed version, and > perhaps the date of installation. The registry stores installation dates. $ port -v installed zlib The following ports are currently installed: zlib @1.2.11_0 (active) requested_variants='' platform='darwin 19' archs='x86_64' date='2021-11-12T12:14:43-0600' Release date information is not available in MacPorts. Are you proposing that the maintainer of every port should do research to discover the release date every time they want to update a port to a new version and add that information to a new field in the portfile? Why? Or are you referring to the date when an update of a portfile was committed to GitHub? If so, why would that be useful to you?
Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?
> On Jan 22, 2022, at 11:13, Ryan Schmidt wrote: > > > > On Jan 22, 2022, at 09:36, Richard L. Hamilton wrote: > >> I have no idea of the difficulty of such a change, but it would be >> interesting if Portfiles contained a release date, and the database of >> installed ports had both a copy of that for any given installed version, and >> perhaps the date of installation. > > The registry stores installation dates. > > $ port -v installed zlib > The following ports are currently installed: > zlib @1.2.11_0 (active) requested_variants='' platform='darwin 19' > archs='x86_64' date='2021-11-12T12:14:43-0600' > > > > > Release date information is not available in MacPorts. Are you proposing that > the maintainer of every port should do research to discover the release date > every time they want to update a port to a new version and add that > information to a new field in the portfile? Why? > > Or are you referring to the date when an update of a portfile was committed > to GitHub? If so, why would that be useful to you? The latter, since the former, although possibly more useful, is too difficult. Ideally, one has active the latest available version of a port, esp. given dependencies. But that doesn't always build, nor even always fail on first use after being built. Some might wish to let stuff age a bit for stability's sake, but not excessively, and dates might help with that. A possible alternative: a reasonably easy way to keep only the most recent X inactive versions of a port with a given set of variants. That way one could keep things reasonably clean but have something to fall back to. If there's a non-manual way to do that (short of a creative script that digests the output of "port installed"), I must have missed it. smime.p7s Description: S/MIME cryptographic signature
