develooper Front page | perl.perl5.porters | Postings from July 2020

Re: Perl 7 - updates

Thread Previous | Thread Next
From:
Kent Fredric
Date:
July 5, 2020 16:45
Subject:
Re: Perl 7 - updates
Message ID:
CAATnKFAujFyFMzi14YbUBG9CTb4pgeja+2uZSRcAGc4-fNy=Aw@mail.gmail.com
On Mon, 6 Jul 2020 at 04:20, David Green
<david.green@pl-comme.ci-comme.ca> wrote:

>
> Distributions won’t want to give up the default perl 5 because they have
> tools that work and don’t need fixing (if it ain’t broke…); but we want
> the default perl not to be stuck on v5 forever. So let’s make
> /usr/bin/perl be versions 5 *and* 7 (or any other versions). Build an
> executable that glues different versions together, so that which one you
> get depends on the name used to invoke it, or on an environmental
> variable.  Apple actually used to use such a Frankenstein-binary to
> provide two different versions of perl in a single file for OS X.

I'd probably ask that this *not* be something done in part of Perl,
maybe it can be a complimentary thing also available to use at a
vendor's discretion, but otherwise independent.

We already have this sort of approach employed in other languages,
Python in particular.

https://github.com/mgorny/python-exec/

Python packages get installed, sometimes, a python package installs
multiple times for each desired interpreter, and the "real scripts"
are stashed somewhere in:

 /usr/lib/python-exec/<PYTHON_VERSION>/script_name

So for an analogy, a package that builds for both perl5 and perl7
would have something like:

 /usr/lib/perl-exec/perl5.30/perldoc
 /usr/lib/perl-exec/perl7.0/perldoc

The actual script in /usr/bin/  is just a *symlink* to
/usr/bin/python-exec ( which in our case, would be /usr/bin/perl-exec
).

And python-exec/perl-exec then makes a decision which implementation
to use, based on inspecting ENV to work out what the users *desired*
implementation is, and make sure it picks a variation within the
*supported* implementations.

And similarly,

    /usr/bin/python

Is itself, a symlink to a binary in the python-exec package, which
again, dispatches to a supported interpreter based on ENV settings.

This is exactly the road I'm defaulting to taking right now, if we
head for dual-deploy at all.

But I just have to work out if it plays nicely with all the perl magic, such as:

- shebang redispatch magic working properly
- $^X doing the right thing (whatever that is for this problem)
- $0 showing the right thing
- And probably some other problems I haven't thought of yet.

But this is a fair amount of work right now *just* to investigate properly.


--
KENTNL - https://metacpan.org/author/KENTNL

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About