Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

support for "use perl5i version => 2" #197

Closed
wants to merge 1 commit into from

2 participants

@dams

This is a proposal for an alternative on how to specify the perl5i version. Why is that useful ? There a re someusage. For instance, the Dist::Zilla AutoPrereqs is confused by "use perl5i::2", and produce a requirement on "perl5i::2" instead of "perl5i". Other issues can be experienced in different cases. It also opens the possibility for global argument management. Also, I like this API :)

@schwern
Owner

Thanks for the work, and I'm sorry it has to be rejected.

Dist::Zilla is doing the right thing, and perl5i's versioning is working according to plan. Distributions should depend on perl5i::2 and not on perl5i. This is deliberately done to protect against when older versions of perl5i are split into their own distributions. This is documented in http://search.cpan.org/perldoc?perl5i#Using_perl5i

For example, let's suppose that perl5i::3 stops using a troublesome dependency like true or Child. We like to get rid of it as a dependency. Dependencies are done at the distribution level, so perl5i::2 would be put into a separate distribution called perl5i-2 (and perl5i::1 into perl5i-1, etc...). perl5i-2 continues depend on DateTime, but perl5i (containing just perl5i::3) no longer has to. Modules that depend on perl5i::2 continue to work. This allows us to completely detach perl5i from its older versions. All part of the backwards incompatibility plan.

use perl5i version => X sugar would confuse packaging tools and obfuscate the simple package-based versioning.

I'm going to close this, but please feel free to continue the conversation.

@schwern schwern closed this
@dams

No problem for rejecting it, and thanks forthe explanation :)
This patch is not lost, as I'm using it in a modified reimplementation of perl5i in our company. As a side note, I tried to avoid reimplementing it, but there were quite a few modules we didn't want to push as standard at $work (like autoboxing), and I didn't know how to use perl5i excluding some of the features.

Anyway, I had understood your versioning system fine, but I didn't get the splitting-in-package point straight away. However, I don't see why you reserve distribution-per-version only for older versions. If current perl5i version had its distribution right now, say "perl5i-2", it would have the benefit of pleasing deployment tools (like dzil), and having "use perl5i::2" work fine. I ca't see the drawbacks, but I'm sure there are some, otherwise you'd have done so ? I find it a bit clunky for now that the perl5i-2 distribution doesn't exist, but that's probably just me :)

Anyway I agree with you that splitting older (and current?) perl5i version has the benefit of allowing its umber of dependancies to reduce as well as grow.

@schwern
Owner

Would you believe laziness? I didn't have the whole backwards incompatibility plan well thought out when I started, but you're right that there's no harm in splitting them now. However, there's practical bits of splitting the distributions to be worked out. The big unresolved issue is how best to fix bugs in both versions, to maintain an older version for a while. Ideally, v2 and v3 would be branches and patches could be cherry picked between them, but that doesn't work if the patch is on perl5i/3.pm and we want it to go onto perl5i/2.pm.

PS Why no autobox?

@dams

I do believe laziness :) I fight it on a day-to-day basis myself... About the unresolved issue : I'm sure you can forge git commits the way you want it, using plumbing commands.

Techically, it's easy to apply a perl5i/3.pm cherry-picked commit on perl5i/2.pm, via patch generation and application (and git am). So the issue is to keep it in sync and hooked together. You can mitigate the issue by annotating the 2 commits on the same GH# issue number (or similar), and you can probably do more, as I said, by crafting your own commits.

no autobox because it was judged too magical and a too big of a change in the way non-advanced Perl devs are using the language. I don't despair to include it at some point, after more training. But I try to keep it simple for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on May 27, 2011
  1. @dams

    allow use perl5i version =>

    dams authored
This page is out of date. Refresh to see the latest.
Showing with 38 additions and 2 deletions.
  1. +27 −1 lib/perl5i.pm
  2. +2 −1  lib/perl5i/VERSION.pm
  3. +9 −0 t/perl5i_alternate.t
View
28 lib/perl5i.pm
@@ -11,12 +11,13 @@ use parent 'perl5i::latest';
use perl5i::VERSION; our $VERSION = perl5i::VERSION->VERSION;
my $Latest = perl5i::VERSION->latest;
+my $LatestVersion = perl5i::VERSION->latest_version;
sub import {
if ($0 eq '-e') {
goto &perl5i::latest::import;
}
- else {
+ elsif ( @_ <= 1) {
require Carp;
Carp::croak(<<END);
perl5i will break compatibility in the future, you can't just "use perl5i".
@@ -24,8 +25,31 @@ perl5i will break compatibility in the future, you can't just "use perl5i".
Instead, "use $Latest" which will guarantee compatibility with all
features supplied in that major version.
+Alternatively, you can "use perl51 version => $LatestVersion"
+
Type "perldoc perl5i" for details in the section "Using perl5i".
END
+ } else {
+ # even number of arguments + $class argument = odd number of arguments
+ unless (@_ % 2) {
+ require Carp;
+ Carp::croak(<<END);
+number of arguments passed to 'use perl5i' should be even.
+END
+ }
+ my ($class, %args) = @_;
+ my $version = $args{version};
+ if (defined $version) {
+ eval { require "perl5i/$version.pm" };
+ $@ or goto &{'perl5i::' . $version . '::import'};
+ require Carp;
+ Carp::croak(<<END);
+there is no version '$version' of perl5i: $. Latest version is $LatestVersion
+END
+ }
+ Carp::croak(<<END);
+arguments passed to 'use perl5i' should contain 'version'. E.g. : 'use perl5i version => $LatestVersion'
+END
}
}
@@ -72,6 +96,8 @@ you are using. You do this like so:
# Use perl5i major version 2
use perl5i::2;
+ # Or
+ use perl5i version => 2;
Thus the code you write with, for example, C<perl5i::2> will always
remain compatible even as perl5i moves on.
View
3  lib/perl5i/VERSION.pm
@@ -7,6 +7,7 @@ use warnings;
use version 0.77; our $VERSION = qv("v2.6.1");
-sub latest { "perl5i::2" }; # LATEST HERE (for automated update)
+sub latest_version { 2 } # LATEST HERE (for automated update)
+sub latest { 'perl5i::' . __PACKAGE__->latest_version }
1;
View
9 t/perl5i_alternate.t
@@ -0,0 +1,9 @@
+#!/usr/bin/env perl
+
+use Test::More;
+
+# using perl5i with a specific version is ok
+eval "use perl5i version => 2";
+ok !$@, "use perl5i version => ...";
+
+done_testing();
Something went wrong with that request. Please try again.