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

Modules, CPAN, and multiple versions

From:
David Green
Date:
July 5, 2020 16:49
Subject:
Modules, CPAN, and multiple versions
Message ID:
20200705164904.409.qmail@lists-nntp.develooper.com
Ideally, Perl would be able handle packages using different versions of 
perl at the same time, so that folks could continue to run a mix of old 
codebases, including old CPAN modules that aren’t getting maintained, 
while using v7 and beyond for new and revised code. However, that’s not 
very feasible because Perl has lots of knotty syntax that is tied 
directly to the parsing code, and the code needs to be able to be 
cleaned up so that Perl remains maintainable.

I hope this means that CPAN gains the ability to handle multiple 
versions of a module, so that you can install one or more versions side 
by side, and the right version of Perl will choose the right module. I 
would also love to see versioning across “authorities”, in the P6 sense 
(think of it as versioning across space as well as time). Then it would 
be possible to have an equivalent version of a module but supplied by 
someone else; and thus, a sane way to handle abandoned modules: instead 
of having to “take over” ownership, a different author(ity) could just 
release a parallel version alongside the original.

Without that ability, modules would have to somehow accommodate 
different versions of Perl in a single file, which I don’t think is 
practical in the long run. However, as Perl changes, many of the 
differences will be small enough that we want to be able to handle minor 
variations within the same file. (I.e. as well as external metadata 
about a module, we want to have metadata that is within a given file.)

To combine different versions of Perl in the same file, we need a way to 
identify separate chunks of the file — and we have a way, namely the one 
already used to identify chunks of POD. The same syntax could be used to 
identify different versions of Perl code, or different purposes (such as 
inline testing), or even different languages!

=pod
This is some documentation.

=testing
ok "This is an inline unit-test";

=perl v5.30
sub foo(&) { ... }

=perl v7.0
sub foo :prototype(&) { ... }

=lang python v3.2
"""Well… maybe some day!"""


Or perhaps some other syntax would be more suitable, but the idea is the 
same; some parts of the file get read (differently by perl5 vs perl7 vs 
perldoc, etc.) and irrelevant parts are simply ignored.

Note that this is a different issue from “use v7” — the POD-like 
sections determine which parts of the file are read (or ignored) by the 
executable before it does anything; once it has read all the relevant 
sections and starts parsing/interpreting, then the “use v__” kicks in. 
(So “=lang perl v5 \n use v7” would get run as P5 and complain about an 
invalid version.)

There is one catch (just one?!): old versions of Perl will read “=perl” 
directives as errors. Apart from saying, “too bad, update your copy of 
perldoc”, I think we could employ “=for” as a more backwards-compatible 
approach:

=for lang perl v.7

Directives like “=head1” might become backwards-compatible shortcuts for 
“=pod head1”.



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