Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants

dams commented May 27, 2011

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 :)

Contributor

schwern commented May 28, 2011

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 May 28, 2011

dams commented May 28, 2011

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.

Contributor

schwern commented May 28, 2011

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 commented May 29, 2011

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