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