Mailing List Archive: Perl: porters

CPAN / new Perl 5 features / Perl upgrade conundrum

1 2

View All

Index | Next | Previous | View Threaded

liz at dijkmat

May 29, 2012, 2:04 AM

Post #1 of 33 (169 views)
Permalink

CPAN / new Perl 5 features / Perl upgrade conundrum

In the past years, Perl 5 has seen a lot of new features added to the language. Some of these features I've been dying to be able to use in my CPAN modules. But alas, if I use these new features, my modules don't run on older versions of Perl anymore.

This is holding back the use of new features in CPAN modules. But it is also removing reasons for people to upgrade existing Perl installations: why would you want to upgrade, if there is no incentive to upgrade (especially in the light that CPAN is considered to be one of the Unique Selling Points of Perl).

As an author, I could envision that I maintain a "maint" version of my module (which would essentially be frozen, but for bugfixes), and a "blead" version of my module that would use new features of Perl and which would have new features added. In other words, provide an incentive to upgrade an existing Perl installation.

Unfortunately, CPAN/cpan is not able to handle multiple versions of the same module very well. So making a "maint" distribution of a module, and a "blead" distribution of a module, is out of the question. So if I want to maintain a "maint" version and a "blead" version of my modules, they would need to live inside the same distribution.

After a few days of testing with one of my modules (Thread::Queue::Any), I think I created a system in which:

1. depending on perl version that runs the Makefile.PL, selects either the "maint" or "blead" version of the code. Then tests and install that version of the code.

2. allows override of the version selection of the code, to allow 'maint' version of code to be installed on newer perls if needed (with "perl Makefile.PL maint").

3. has different version numbers for "maint" (0.13) and "blead" (1.04) version of the code. So that it is easier to track problems in the wild.

4. shows up in searches in search.cpan.org with both versions (I consider that a bonus, as the documentation of each version clearly states about which version it is).

5. shows up on MetaCPAN with just the "blead" documentation.

I'm pretty happy with this situation: people upgrading Perl modules on a system with an older Perl, will not see any breakage (because they will continue using the "maint" code). And if they upgrade their Perl, they will automatically get the "blead" version of the code, which will not cause any breakage then either.

I therefor plan to upgrade all of my modules on CPAN in the same manner in the coming months. Unless someone convinces me this is a bad idea.

So my question to p5p is: is this a valid / good way forward?

Suggestions / Remarks / Opinions very welcome!

Liz

eda at waniasset

May 29, 2012, 5:28 AM

Post #2 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

I appreciate that at present the CPAN tools aren't able to handle
multiple versions of a module very well, so it is hard to maintain an
older version for older Perls as well as a newer version. But putting
the two in the same distribution tarball seems like it complicates
things further, hiding the choice of versions from the CPAN shell and,
to some extent, the user.

I think we all agree that the ideal solution is for 'perl -S cpan' and
other tools to handle multiple versions, and intelligently pick the
right version of a module for the version of Perl that is installed.
Given that at the moment it does not, the question is what is the
least bad workaround.

Might I suggest instead that the newer version of the module get a new
name; so you have Foo version 2.3 which supports older Perls, and
Foo_3 version 3.0 which is the latest version and requires a later
Perl version. Although the package name and distribution tarball name
is Foo_3, it provides a stub package Foo for backwards compatibility,
so user code doesn't need to change.

Then somebody who wants the newer release can say 'cpan -S Foo_3', or
can build an rpm package from the Foo_3 distribution, and so on. This
also leaves the user the choice of installing the older version if he
or she wants.

The scheme of two versions in the same tarball would work, I expect,
but packaging and dependency management is already complicated, and we
have to avoid anything which makes it more complicated. Better to
have an explicit choice and a new name rather than something which
chooses a version automatically outside of the packaging system's
control.

--
Ed Avis <eda [at] waniasset>

jvromans at squirrel

May 29, 2012, 7:59 AM

Post #3 of 33 (162 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

Ed Avis <eda [at] waniasset> writes:

> Might I suggest instead that the newer version of the module get a new
> name; so you have Foo version 2.3 which supports older Perls, and
> Foo_3 version 3.0 which is the latest version and requires a later
> Perl version.

I think this is a bad idea.

It's not a new module, it's not even a new version of a module. It's the
same module that now, for some reason, requires more of Perl than the
older version did.

If anything must be renamed, it's the older module - like Foo_Old.

-- Johan

liz at dijkmat

May 29, 2012, 9:57 AM

Post #4 of 33 (160 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On May 29, 2012, at 2:28 PM, Ed Avis wrote:
> I appreciate that at present the CPAN tools aren't able to handle
> multiple versions of a module very well, so it is hard to maintain an
> older version for older Perls as well as a newer version. But putting
> the two in the same distribution tarball seems like it complicates
> things further, hiding the choice of versions from the CPAN shell and,
> to some extent, the user.
>
> I think we all agree that the ideal solution is for 'perl -S cpan' and
> other tools to handle multiple versions, and intelligently pick the
> right version of a module for the version of Perl that is installed.
> Given that at the moment it does not, the question is what is the
> least bad workaround.
>
> Might I suggest instead that the newer version of the module get a new
> name; so you have Foo version 2.3 which supports older Perls, and
> Foo_3 version 3.0 which is the latest version and requires a later
> Perl version. Although the package name and distribution tarball name
> is Foo_3, it provides a stub package Foo for backwards compatibility,
> so user code doesn't need to change.

That was my initial take as well. But PAUSE / CPAN / MetaCPAN choose to look inside files and determine from that whether they supply a certain package. And that way, it becomes even more complicated. (I know from experience with the "forks" module, which fakes the "threads" module).

> Then somebody who wants the newer release can say 'cpan -S Foo_3', or
> can build an rpm package from the Foo_3 distribution, and so on. This
> also leaves the user the choice of installing the older version if he
> or she wants.

RPM packages are built with a specific version of Perl. If that perl is using the "maint" version of the code, then it will get the version number of the "maint" version. Which is different from the "blead" version. And the "blead" version number is always higher than the "maint" version number. So the name of a generated RPM is always indicative of whether it is a "maint" or "blead" version.

> The scheme of two versions in the same tarball would work, I expect,
> but packaging and dependency management is already complicated, and we
> have to avoid anything which makes it more complicated. Better to
> have an explicit choice and a new name rather than something which
> chooses a version automatically outside of the packaging system's
> control.

But I've allowed a form of control:

perl Makefile.PL maint

will use the "maint" version of the code, regardless of the version of Perl that you're using. In that sense, I don't think it is any different from any other distribution that allows parameters to be specified with the running of Makefile.PL.

Thanks for your thoughts!

Liz

eda at waniasset

May 29, 2012, 10:03 AM

Post #5 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

I guess I would add that 'maint' and 'blead' are not good names, if you intend to provide two versions which are both suitable for production use. ('Blead' in perl connotes a test version, and 'maint' the most recent production release, as I understand it.) Better to pick a new major version number - say you have 2.x and 3.x - and then users choose between 2 and 3.

But anyway, what is the reason why not to just release the latest version to CPAN? The older versions are still there, and users who don't upgrade don't upgrade.

--
Ed Avis

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

liz at dijkmat

May 29, 2012, 10:10 AM

Post #6 of 33 (162 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On May 29, 2012, at 4:59 PM, Johan Vromans wrote:
> Ed Avis <eda [at] waniasset> writes:
>> Might I suggest instead that the newer version of the module get a new
>> name; so you have Foo version 2.3 which supports older Perls, and
>> Foo_3 version 3.0 which is the latest version and requires a later
>> Perl version.
> I think this is a bad idea.

Indeed. As I said, this has its problems.

> It's not a new module, it's not even a new version of a module. It's the
> same module that now, for some reason, requires more of Perl than the
> older version did.

The idea is that any code out there using an older perl (and therefore using the "maint" version of the module), should continue to work. If at one time, that system's perl is upgraded (*and* thereby the "blead" version of the module is installed), that code should *still* continue to work without any changes (no API changes between "maint" and "blead", only additional features!).

Only developers needing the new features of the module, will need to have their perls upgraded to be able to use these new features. And thereby providing an incentive for people to have their perl upgraded.

> If anything must be renamed, it's the older module - like Foo_Old.

If you're talking about the -package- name, we will break existing code. If you're talking about distribution name, then search.cpan.org / MetaCPAN gets confused.

Please note that internally, inside the distribution, there is always a "normal" file structure in place (by default, the "blead" one, in lib and t). The other state of the code lives in other directories (lib_maint,t_maint) with the files in there having another extension (.pm_maint, .t_maint). Switching between states, is a matter of moving files between the "state" directories and changing the extensions.

Liz

liz at dijkmat

May 29, 2012, 10:16 AM

Post #7 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On May 29, 2012, at 7:03 PM, Ed Avis wrote:
> I guess I would add that 'maint' and 'blead' are not good names, if you intend to provide two versions which are both suitable for production use. ('Blead' in perl connotes a test version, and 'maint' the most recent production release, as I understand it.) Better to pick a new major version number - say you have 2.x and 3.x - and then users choose between 2 and 3.

In fact, "blead" in the Thread::Queue::Any case, is at 1.x, whereas "maint" is still at 0.x.

But indeed, maybe the phrases "maint" and "blead" are confusing.

> But anyway, what is the reason why not to just release the latest version to CPAN? The older versions are still there, and users who don't upgrade don't upgrade.

Indeed. That would be the simplest way. But this has the serious danger of breaking existing code out there. I don't want to do that. And if people should find bugs in the "maint" version, I still want to be able to fix those for those users, without getting into very weird version numbering territory. The setup I devised, allows me to do just that as well.

Liz

kentfredric at gmail

May 29, 2012, 10:39 AM

Post #8 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On 30 May 2012 05:16, Elizabeth Mattijsen <liz [at] dijkmat> wrote:
>> But anyway, what is the reason why not to just release the latest version to CPAN? The older versions are still there, and users who don't upgrade don't upgrade.
>
> Indeed. That would be the simplest way. But this has the serious danger of breaking existing code out there.

As long as you depend on the features you need, ie: depending on the
newer perl to support your new feature, the user shouldn't be able to
upgrade and "break existing code", as any sane CPAN client bails if
your module declares a dependency on a version of perl higher than the
present one.

You can of course force this restriction, but thats breaking things
intentionally.

And as long as you leave the older versions around, they can at least
still manually upgrade to it.

The only real pain there is when something depends on you, it will
likely only try install the latest version of your module, and won't
have the capacity/foresight to automatically walk back through the
older versions till it finds one compatible with the present perl. (
A niche for somebody to write a module that uses data from metacpan
exists here! ;D )

--
kentnl

liz at dijkmat

May 29, 2012, 10:43 AM

Post #9 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On May 29, 2012, at 7:39 PM, Kent Fredric wrote:
> On 30 May 2012 05:16, Elizabeth Mattijsen <liz [at] dijkmat> wrote:
>>> But anyway, what is the reason why not to just release the latest version to CPAN? The older versions are still there, and users who don't upgrade don't upgrade.
>>
>> Indeed. That would be the simplest way. But this has the serious danger of breaking existing code out there.
>
> As long as you depend on the features you need, ie: depending on the
> newer perl to support your new feature, the user shouldn't be able to
> upgrade and "break existing code", as any sane CPAN client bails if
> your module declares a dependency on a version of perl higher than the
> present one.
>
> You can of course force this restriction, but thats breaking things
> intentionally.
>
> And as long as you leave the older versions around, they can at least
> still manually upgrade to it.

Selected older versions will be kept around, indeed.

> The only real pain there is when something depends on you, it will
> likely only try install the latest version of your module, and won't
> have the capacity/foresight to automatically walk back through the
> older versions till it finds one compatible with the present perl.

Indeed. And that is what my "system" solves.

> (A niche for somebody to write a module that uses data from metacpan
> exists here! ;D )

I'm not sure how you would be able to do that. I would think that only the developer has the information on what version of the code can run where. Or are there some meta tags I don't know about?

Liz

abigail at abigail

May 29, 2012, 12:29 PM

Post #10 of 33 (166 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On Tue, May 29, 2012 at 07:16:30PM +0200, Elizabeth Mattijsen wrote:
> On May 29, 2012, at 7:03 PM, Ed Avis wrote:
> > I guess I would add that 'maint' and 'blead' are not good names, if you intend to provide two versions which are both suitable for production use. ('Blead' in perl connotes a test version, and 'maint' the most recent production release, as I understand it.) Better to pick a new major version number - say you have 2.x and 3.x - and then users choose between 2 and 3.
>
> In fact, "blead" in the Thread::Queue::Any case, is at 1.x, whereas "maint" is still at 0.x.
>
> But indeed, maybe the phrases "maint" and "blead" are confusing.
>
>
> > But anyway, what is the reason why not to just release the latest version to CPAN? The older versions are still there, and users who don't upgrade don't upgrade.
>
> Indeed. That would be the simplest way. But this has the serious
> danger of breaking existing code out there. I don't want to do that.

How's that? Isn't that what "use 5.XXX" and MIN_PERL_VERSION are for?

> And if people should find bugs in the "maint" version, I still want to
> be able to fix those for those users, without getting into very weird
> version numbering territory. The setup I devised, allows me to do just
> that as well.

I'm not quite sure what it is you want to do. I've a hard time to come with
functionality that actually requires a Perl that was released in the 21st
century, except for some patterns and Unicode stuff. But you were talking
about upgrading all your modules. Can you give an example of what you want
to do?

Anyway, the way I would do it is one of:

eval <<"--" if $] >= 5.010;
... stuff that requires 5.010 ...
--
eval <<"--" if $] >= 5.012;
... stuff that requires 5.012 ...
--
eval <<"--" if $] >= 5.014;
... stuff that requires 5.014 ...
--
eval <<"--" if $] >= 5.016;
... stuff that requires 5.016 ...
--

or

use if $] >= 5.010, 'My::Module::perl5010';
use if $] >= 5.012, 'My::Module::perl5012';
use if $] >= 5.014, 'My::Module::perl5014';
use if $] >= 5.016, 'My::Module::perl5016';

Abigail

liz at dijkmat

May 29, 2012, 2:14 PM

Post #11 of 33 (166 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On May 29, 2012, at 9:29 PM, Abigail wrote:
> On Tue, May 29, 2012 at 07:16:30PM +0200, Elizabeth Mattijsen wrote:
>> On May 29, 2012, at 7:03 PM, Ed Avis wrote:
>>> I guess I would add that 'maint' and 'blead' are not good names, if you intend to provide two versions which are both suitable for production use. ('Blead' in perl connotes a test version, and 'maint' the most recent production release, as I understand it.) Better to pick a new major version number - say you have 2.x and 3.x - and then users choose between 2 and 3.
>>
>> In fact, "blead" in the Thread::Queue::Any case, is at 1.x, whereas "maint" is still at 0.x.
>>
>> But indeed, maybe the phrases "maint" and "blead" are confusing.
>>
>>
>>> But anyway, what is the reason why not to just release the latest version to CPAN? The older versions are still there, and users who don't upgrade don't upgrade.
>>
>> Indeed. That would be the simplest way. But this has the serious
>> danger of breaking existing code out there. I don't want to do that.
> How's that? Isn't that what "use 5.XXX" and MIN_PERL_VERSION are for?

What I want for Perl is a reason for organizations to upgrade their perl to a more recent version. This can be achieved by adding new features to CPAN modules that are written using newer Perl features.

What I want for P5Pers, is that they can eat their own dogfood (aka features of newer perls) in the CPAN modules that they maintain.

What I want for a packager / sysadmin who decides to upgrade a distribution to the latest and greatest (for whatever reason, in whatever environment), to not have to suddenly have to deal with the fact that the distribution won't work with the perl version that they have / want to migrate to.

What I want for myself, is an easy way to start up a new "base" version of a distribution, using all new Perl features (if just for the fact that I want to get experience with said new features of Perl).

>> And if people should find bugs in the "maint" version, I still want to
>> be able to fix those for those users, without getting into very weird
>> version numbering territory. The setup I devised, allows me to do just
>> that as well.
>
> I'm not quite sure what it is you want to do. I've a hard time to come with
> functionality that actually requires a Perl that was released in the 21st
> century, except for some patterns and Unicode stuff.

Other people might want to use other new features. This could be as simple as being able to use // or when. The meme I've been seeing a lot lately, is that all these new Perl features are fine, but you can't use them in CPAN modules, because in the world out there, everybody is still using 5.8.x.

This is a chicken and egg problem. Organizations won't upgrade because there is no real reason to. New features cannot be used, because organizations don't upgrade.

I think that everybody agrees that CPAN is one of the main reasons people (still) use Perl. What we're seeing now is that on the one hand, we have significant developments in the Perl 5 language. But the modules on CPAN, one of the USP's of Perl, are still not using all those new features. What kind of message are we sending with that?

> But you were talking
> about upgrading all your modules. Can you give an example of what you want
> to do?

convert:

$self->{'maxjobs'} = 5 * ($add || 1) unless defined( $self->{'maxjobs'} );

to:

$self->{maxjobs} //= 5 * ( $add || 1 );

converting long winded if/elsif constructs all checking $_ to using when

Stuff like that.

> Anyway, the way I would do it is one of:
>
>
> eval <<"--" if $] >= 5.010;
> ... stuff that requires 5.010 ...
> --
> eval <<"--" if $] >= 5.012;
> ... stuff that requires 5.012 ...
> --
> eval <<"--" if $] >= 5.014;
> ... stuff that requires 5.014 ...
> --
> eval <<"--" if $] >= 5.016;
> ... stuff that requires 5.016 ...
> --

Sorry, I don't want to get into the situation of having to support different versions of Perl in a single file. That way lies madness.

> use if $] >= 5.010, 'My::Module::perl5010';
> use if $] >= 5.012, 'My::Module::perl5012';
> use if $] >= 5.014, 'My::Module::perl5014';
> use if $] >= 5.016, 'My::Module::perl5016';

Again, this causes all sorts of havoc on CPAN, when different distributions have the same package declarations internally.

Anyway, this would require code changes on the user code side. I want to remain completely transparent as to the code using my module. If the code uses the "maint" set of features, it doesn't matter whether the "maint" or "blead" version of the module is loaded / installed. If the code needs new features of a module, an upgrade of Perl is required. At least that way, organizations have an incentive to upgrade.

Liz

abigail at abigail

May 29, 2012, 3:42 PM

Post #12 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On Tue, May 29, 2012 at 11:14:02PM +0200, Elizabeth Mattijsen wrote:
> On May 29, 2012, at 9:29 PM, Abigail wrote:
> > On Tue, May 29, 2012 at 07:16:30PM +0200, Elizabeth Mattijsen wrote:
> >> On May 29, 2012, at 7:03 PM, Ed Avis wrote:
> >>> I guess I would add that 'maint' and 'blead' are not good names, if you intend to provide two versions which are both suitable for production use. ('Blead' in perl connotes a test version, and 'maint' the most recent production release, as I understand it.) Better to pick a new major version number - say you have 2.x and 3.x - and then users choose between 2 and 3.
> >>
> >> In fact, "blead" in the Thread::Queue::Any case, is at 1.x, whereas "maint" is still at 0.x.
> >>
> >> But indeed, maybe the phrases "maint" and "blead" are confusing.
> >>
> >>
> >>> But anyway, what is the reason why not to just release the latest version to CPAN? The older versions are still there, and users who don't upgrade don't upgrade.
> >>
> >> Indeed. That would be the simplest way. But this has the serious
> >> danger of breaking existing code out there. I don't want to do that.
> > How's that? Isn't that what "use 5.XXX" and MIN_PERL_VERSION are for?
>
> What I want for Perl is a reason for organizations to upgrade their perl to a more recent version. This can be achieved by adding new features to CPAN modules that are written using newer Perl features.
>
> What I want for P5Pers, is that they can eat their own dogfood (aka features of newer perls) in the CPAN modules that they maintain.
>
> What I want for a packager / sysadmin who decides to upgrade a distribution to the latest and greatest (for whatever reason, in whatever environment), to not have to suddenly have to deal with the fact that the distribution won't work with the perl version that they have / want to migrate to.
>
> What I want for myself, is an easy way to start up a new "base" version of a distribution, using all new Perl features (if just for the fact that I want to get experience with said new features of Perl).
>
>
> >> And if people should find bugs in the "maint" version, I still want to
> >> be able to fix those for those users, without getting into very weird
> >> version numbering territory. The setup I devised, allows me to do just
> >> that as well.
> >
> > I'm not quite sure what it is you want to do. I've a hard time to come with
> > functionality that actually requires a Perl that was released in the 21st
> > century, except for some patterns and Unicode stuff.
>
> Other people might want to use other new features. This could be as
> simple as being able to use // or when. The meme I've been seeing a
> lot lately, is that all these new Perl features are fine, but you can't
> use them in CPAN modules, because in the world out there, everybody is
> still using 5.8.x.

Everyone is free to put anything on CPAN they like. If you want to put code
out there that requires 5.16, there's noone stopping you.

> This is a chicken and egg problem. Organizations won't upgrade
> because there is no real reason to. New features cannot be used,
> because organizations don't upgrade.
>
> I think that everybody agrees that CPAN is one of the main reasons
> people (still) use Perl. What we're seeing now is that on the one
> hand, we have significant developments in the Perl 5 language. But the
> modules on CPAN, one of the USP's of Perl, are still not using all those
> new features. What kind of message are we sending with that?
>
>
>
> > But you were talking
> > about upgrading all your modules. Can you give an example of what you want
> > to do?
>
> convert:
>
> $self->{'maxjobs'} = 5 * ($add || 1) unless defined( $self->{'maxjobs'} );
>
> to:
>
> $self->{maxjobs} //= 5 * ( $add || 1 );
>
>
> converting long winded if/elsif constructs all checking $_ to using when
>
> Stuff like that.

I don't get it.

That's just replacing the same functionality with a different way of
writing it. If you keep both the old and the new way available, then
there's no benefit for the user to upgrade, nor is there any benefit
for yourself, and you'll be maintaining two code paths, one "modern",
one "old".

If your goal is to "push" organizations to upgrade their Perl by means
of CPAN modules, write a killer module, and *don't* have an alternative
"old style" version available.

> > Anyway, the way I would do it is one of:
> >
> >
> > eval <<"--" if $] >= 5.010;
> > ... stuff that requires 5.010 ...
> > --
> > eval <<"--" if $] >= 5.012;
> > ... stuff that requires 5.012 ...
> > --
> > eval <<"--" if $] >= 5.014;
> > ... stuff that requires 5.014 ...
> > --
> > eval <<"--" if $] >= 5.016;
> > ... stuff that requires 5.016 ...
> > --
>
> Sorry, I don't want to get into the situation of having to support different
> versions of Perl in a single file. That way lies madness.
>
> > use if $] >= 5.010, 'My::Module::perl5010';
> > use if $] >= 5.012, 'My::Module::perl5012';
> > use if $] >= 5.014, 'My::Module::perl5014';
> > use if $] >= 5.016, 'My::Module::perl5016';
>
> Again, this causes all sorts of havoc on CPAN, when different distributions
> have the same package declarations internally.

There's no different distributions. There's just one distribution
my-module-1234.5.67.tar.gz, which contains:
lib/My/Module.pm (anything not rewritten)
lib/My/Module/perl5010.pm (anything that requires 5.010)
lib/My/Module/perl5012.pm (anything that requires 5.012)
lib/My/Module/perl5014.pm (anything that requires 5.014)
lib/My/Module/perl5016.pm (anything that requires 5.016)

> Anyway, this would require code changes on the user code side. I want
> to remain completely transparent as to the code using my module. If the
> code uses the "maint" set of features, it doesn't matter whether the
> "maint" or "blead" version of the module is loaded / installed. If the
> code needs new features of a module, an upgrade of Perl is required.
> At least that way, organizations have an incentive to upgrade.

Why would that require any code changes? I presume the user had to do

use My::Module;

before, and I see no reason that would no longer work.

The 'use if' block would appear inside My/Module.pm of course.

Abigail

kentfredric at gmail

May 29, 2012, 4:34 PM

Post #13 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On 30 May 2012 09:14, Elizabeth Mattijsen <liz [at] dijkmat> wrote:

Another strategy you could employ:

1. Release only blead versions to CPAN
2. Have a maint branch with periodic "release" builds, but those
release builds only available on a private location that *isn't* CPAN.

Results: People who do *really* need versions of your module that work
with their version of Perl can still get it, just at extra hassle.
Some people will demand that your module be installable from CPAN, but
they can't really have their cake and eat it too.

If they want the latest on CPAN, they have to have the latest Perl.

If they want ancient perl, but an "up-to-date" version of your module,
they can easily get it from your off-cpan location.

In a way, you're making them pick what reliability that matters to them.

But If you do this, please make sure your maint branch is available
for public contribution via something like github, that way people who
care about legacy perls can keep your software working on legacy perls
for you if they really care that much.

--
kentnl

perl.p5p at rjbs

May 29, 2012, 7:23 PM

Post #14 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

* Abigail <abigail [at] abigail> [2012-05-29T18:42:08]
> That's just replacing the same functionality with a different way of
> writing it. If you keep both the old and the new way available, then
> there's no benefit for the user to upgrade, nor is there any benefit
> for yourself, and you'll be maintaining two code paths, one "modern",
> one "old".
>
> If your goal is to "push" organizations to upgrade their Perl by means
> of CPAN modules, write a killer module, and *don't* have an alternative
> "old style" version available.

That was my thinking as well.

--
rjbs

Attachments:

signature.asc (0.48 KB)

liz at dijkmat

May 29, 2012, 11:01 PM

Post #15 of 33 (162 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On May 30, 2012, at 12:42 AM, Abigail wrote:
*snip*
>> Other people might want to use other new features. This could be as
>> simple as being able to use // or when. The meme I've been seeing a
>> lot lately, is that all these new Perl features are fine, but you can't
>> use them in CPAN modules, because in the world out there, everybody is
>> still using 5.8.x.
> Everyone is free to put anything on CPAN they like. If you want to put code
> out there that requires 5.16, there's noone stopping you.

Indeed, there isn't.

*snip*
>>> But you were talking
>>> about upgrading all your modules. Can you give an example of what you want
>>> to do?
>>
>> convert:
>>
>> $self->{'maxjobs'} = 5 * ($add || 1) unless defined( $self->{'maxjobs'} );
>>
>> to:
>>
>> $self->{maxjobs} //= 5 * ( $add || 1 );
>>
>> converting long winded if/elsif constructs all checking $_ to using when
>> Stuff like that.
> I don't get it.
>
> That's just replacing the same functionality with a different way of
> writing it. If you keep both the old and the new way available, then
> there's no benefit for the user to upgrade, nor is there any benefit
> for yourself, and you'll be maintaining two code paths, one "modern",
> one "old".

I will be maintaining two code paths anyway.

I'm hoping the old code path won't need much attention.

The modern code path would be my new (personal) "standard" of developing modules. A refactor if you will. On which I will build new functionality.

> If your goal is to "push" organizations to upgrade their Perl by means
> of CPAN modules, write a killer module, and *don't* have an alternative
> "old style" version available.

I'm working on that as well. :-) But I'm not abandoning my old distributions. Unless they really don't make sense anymore. For those distributions, there's backpan.

>>> use if $] >= 5.010, 'My::Module::perl5010';
>>> use if $] >= 5.012, 'My::Module::perl5012';
>>> use if $] >= 5.014, 'My::Module::perl5014';
>>> use if $] >= 5.016, 'My::Module::perl5016';
>>
>> Again, this causes all sorts of havoc on CPAN, when different distributions
>> have the same package declarations internally.
>
> There's no different distributions. There's just one distribution
> my-module-1234.5.67.tar.gz, which contains:
> lib/My/Module.pm (anything not rewritten)
> lib/My/Module/perl5010.pm (anything that requires 5.010)
> lib/My/Module/perl5012.pm (anything that requires 5.012)
> lib/My/Module/perl5014.pm (anything that requires 5.014)
> lib/My/Module/perl5016.pm (anything that requires 5.016)

This is effectively what I'm doing. But then at install time, rather than at compile time.

But even that can cause confusion. On search.cpan.org you get to see the 0.13 version of the pod for Thread::Queue::Any 1.04 distribution, if clicked from the distribution page (http://search.cpan.org/~elizabeth/Thread-Queue-Any/ ). And that's even with a file that doesn't even have the .pm extension. Just the mere occurrence of a -package- statement in the code, seems to be enough.

>> Anyway, this would require code changes on the user code side. I want
>> to remain completely transparent as to the code using my module. If the
>> code uses the "maint" set of features, it doesn't matter whether the
>> "maint" or "blead" version of the module is loaded / installed. If the
>> code needs new features of a module, an upgrade of Perl is required.
>> At least that way, organizations have an incentive to upgrade.
>
> Why would that require any code changes? I presume the user had to do
>
> use My::Module;
>
> before, and I see no reason that would no longer work.
>
> The 'use if' block would appear inside My/Module.pm of course.

That I didn't get. Got you now.

Liz

liz at dijkmat

May 29, 2012, 11:10 PM

Post #16 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On May 30, 2012, at 1:34 AM, Kent Fredric wrote:
> On 30 May 2012 09:14, Elizabeth Mattijsen <liz [at] dijkmat> wrote:
>
> Another strategy you could employ:
>
> 1. Release only blead versions to CPAN
> 2. Have a maint branch with periodic "release" builds, but those
> release builds only available on a private location that *isn't* CPAN.
>
> Results: People who do *really* need versions of your module that work
> with their version of Perl can still get it, just at extra hassle.
> Some people will demand that your module be installable from CPAN, but
> they can't really have their cake and eat it too.

Well, I *was* going for that.

But I'm now considering *not* doing any automatic selection. Instead, Makefile.PL will *always* try to install the "blead" version of the code, and fail with a descriptive message if it cannot install because the perl version is not sufficient. And with instructions to call Makefile.PL with the "maint" parameter, if one wants to install the "maint" version of the module instead.

That way, packagers still would have the option of simply packaging the "maint" version of the module, but would not be surprised if that happened automatically.

And I'll provide an environment variable to set to get the current "automatic" behavior.

> If they want the latest on CPAN, they have to have the latest Perl.
>
> If they want ancient perl, but an "up-to-date" version of your module,
> they can easily get it from your off-cpan location.

They wouldn't have to do that then. They would either simply need to set an environment variable, or provide an extra parameter in the packaging / install process.

> In a way, you're making them pick what reliability that matters to them.

Indeed.

> But If you do this, please make sure your maint branch is available
> for public contribution via something like github, that way people who
> care about legacy perls can keep your software working on legacy perls
> for you if they really care that much.

With the above approach, this wouldn't be necessary. Which would mean less hassle for me at the moment.

Thank you all for your thoughts!

Liz

bulk88 at hotmail

May 30, 2012, 2:18 AM

Post #17 of 33 (161 views)
Permalink

RE: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

Assuming you use EUMM, why do you not select the correct pm file inside makefile.pl from $]? From reading through Thread::Queue::Any's makefile.pl I think you already do that. That is the best way.

I'll try to challenge every other opinion in this thread, for the sake of discussion. I dont necessarily agree with my opinions here.

About some of the other opinions, I don't see a reason to break automated packagers and smokers/testers� with off CPAN releases or hand entered makefile macros. One of my ways of thinking about it is, I downloaded this CPAN module so I don't have to write it myself. Why should I finish writing it for the author if the author didn't care enough to have defaults and autodetection for a "basic" or "simple" installation? If need super programing skills just to use this CPAN module, I might as well write my own competing CPAN module and slap it on my resume. This must be another abandoned alpha module. A automated packager failing to build it, unless the module's purpose is very specific such as being a wrapper for an outside C library, just adds to the judgment call that this is an unsupported alpha module. I'll just keep looking on CPAN for a higher quality module, which there usually is. TIMTOWTDI is a great part about CPAN. Its a better use of my time than figuring out the defaults that should have been in there in the first place. The decision only takes a few seconds for anyone to make. After using the module, I might decide I want to change the build defaults, thats my choice, and your choice to have such options, but you must have defaults that work out of the box or I give up and keep searching.

About keeping backwards compatibility with older perls. I suggest to do it as long as possible.Just because its old, doesn't mean its broken or flawed or dangerous (not always, security, etc). It wasn't broken when it came out, and millions of PCs ran that perl uneventfully. I personally test to Perl 5.10. I probably code to 5.6 or 5.8. ppport.h is enough for me. I see no reason personally to target a newer perl code wise.

One opinion in the thread is, people are __(something negative)____ and won't upgrade their Perls unless they have a reason, so CPAN authors need to force people to upgrade their perls for ___(something positive)____ so the CPAN authors should always require the latest perl to use the CPAN authors' module. In my opinion, that sounds oppressive. Someone else would say, "my module, my rules". My answer, fine, fork time. It shouldn't get to the fork point though. If someone asks you to support an old perl, and it takes only a couple minutes to do so, a reasonable person would support the old perl. If someone asks you to backport operator overloading to Perl 4, tell them you want a patch with test suite included.

For the opinion that large or corporate entities should be forced to upgrade to newer Perls, you will not convince them to upgrade. If they will budget an upgrade and testing to their software at this point, it will be away from the Perl language.

For the p5p should eat dogfood opinion. They do, it is just not on CPAN. CPAN modules can't do anything on their own. They aren't apps. They are written for the public. They are not written privately, unless their author is A. U. Thor;-)

david at cantrell

May 30, 2012, 4:06 AM

Post #18 of 33 (165 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On Tue, May 29, 2012 at 11:04:55AM +0200, Elizabeth Mattijsen wrote:

> In the past years, Perl 5 has seen a lot of new features added to the language. Some of these features I've been dying to be able to use in my CPAN modules. But alas, if I use these new features, my modules don't run on older versions of Perl anymore.

This is why I wrote and maintain cpXXXan.

If you're stuck on perl 5.6.2 for whatever reason, just use
cp5.6.2an.barnyard.co.uk as your CPAN mirror, and you'll get the latest
version of any distribution which passes its tests on 5.6.2. For
example, you'll get DBI 1.604, because that's the last version to pass
its tests.

--
David Cantrell | top google result for "internet beard fetish club"

Are you feeling bored? depressed? slowed down? Evil Scientists may
be manipulating the speed of light in your vicinity. Buy our patented
instructional video to find out how, and maybe YOU can stop THEM

david at cantrell

May 30, 2012, 4:19 AM

Post #19 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On Tue, May 29, 2012 at 06:03:12PM +0100, Ed Avis wrote:

> But anyway, what is the reason why not to just release the latest version to CPAN? The older versions are still there, and users who don't upgrade don't upgrade.

People who don't upgrade *perl* still maintain and extend their own
applications. If the new feature they're adding needs a new module,
or it needs an upgraded module with a new feature, then it would be
nice to somehow automagically get a version of the module that works
on their version of perl.

Having the toolchain be capable of installing the right version of the
module in question, instead of people having to maintain all their
dependencies by hand, is a Big Win.

--
David Cantrell | Cake Smuggler Extraordinaire

PLEASE NOTE: This message was meant to offend everyone equally,
regardless of race, creed, sexual orientation, politics, choice
of beer, operating system, mode of transport, or their editor.

philippe.bruhat at free

May 30, 2012, 5:04 AM

Post #20 of 33 (162 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On Tue, May 29, 2012 at 09:29:49PM +0200, Abigail wrote:
> On Tue, May 29, 2012 at 07:16:30PM +0200, Elizabeth Mattijsen wrote:
> > On May 29, 2012, at 7:03 PM, Ed Avis wrote:
> > > I guess I would add that 'maint' and 'blead' are not good names, if you intend to provide two versions which are both suitable for production use. ('Blead' in perl connotes a test version, and 'maint' the most recent production release, as I understand it.) Better to pick a new major version number - say you have 2.x and 3.x - and then users choose between 2 and 3.
> >
> > In fact, "blead" in the Thread::Queue::Any case, is at 1.x, whereas "maint" is still at 0.x.
> >
> > But indeed, maybe the phrases "maint" and "blead" are confusing.
> >
> >
> > > But anyway, what is the reason why not to just release the latest version to CPAN? The older versions are still there, and users who don't upgrade don't upgrade.
> >
> > Indeed. That would be the simplest way. But this has the serious
> > danger of breaking existing code out there. I don't want to do that.
>
> How's that? Isn't that what "use 5.XXX" and MIN_PERL_VERSION are for?
>

And then you can put a v2.xx on CPAN that has a use 5.016 in its PL files,
while the v1.xx has a use 5.008 there.

And there probably could be a bunch of extra index files using that
information to make indices of stuff "assumed to work" with Perl >= 5.xxx.
And make the CPAN clients aware of that (via a CPAN::Common module?).

--
Philippe Bruhat (BooK)

You are never too old to have your seat tanned by your Grandmother.
(Moral from Groo The Wanderer #41 (Epic))

fawaka at gmail

May 30, 2012, 5:51 AM

Post #21 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On Tue, May 29, 2012 at 9:29 PM, Abigail <abigail [at] abigail> wrote:
> I'm not quite sure what it is you want to do. I've a hard time to come with
> functionality that actually requires a Perl that was released in the 21st
> century, except for some patterns and Unicode stuff.

In my experience, the unavoidable compatibility dropping is rarely in
syntactical features. I use say and // all of the time in scripts, but
I can live with avoiding them in CPAN modules. It's "deep" features
(e.g. improved hints hash in 5.10+) that make the difference. Though
many of these features are only available in XS anyway (e.g. keyword
plugins)

Leon

mpeters at plusthree

May 30, 2012, 6:40 AM

Post #22 of 33 (164 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On 05/30/2012 02:01 AM, Elizabeth Mattijsen wrote:
> On May 30, 2012, at 12:42 AM, Abigail wrote:
> *snip*
>>> Other people might want to use other new features. This could be as
>>> simple as being able to use // or when. The meme I've been seeing a
>>> lot lately, is that all these new Perl features are fine, but you can't
>>> use them in CPAN modules, because in the world out there, everybody is
>>> still using 5.8.x.
>> Everyone is free to put anything on CPAN they like. If you want to put code
>> out there that requires 5.16, there's noone stopping you.
>
> Indeed, there isn't.
>
> *snip*
>>>> But you were talking
>>>> about upgrading all your modules. Can you give an example of what you want
>>>> to do?
>>>
>>> convert:
>>>
>>> $self->{'maxjobs'} = 5 * ($add || 1) unless defined( $self->{'maxjobs'} );
>>>
>>> to:
>>>
>>> $self->{maxjobs} //= 5 * ( $add || 1 );
>>>
>>> converting long winded if/elsif constructs all checking $_ to using when
>>> Stuff like that.
>> I don't get it.
>>
>> That's just replacing the same functionality with a different way of
>> writing it. If you keep both the old and the new way available, then
>> there's no benefit for the user to upgrade, nor is there any benefit
>> for yourself, and you'll be maintaining two code paths, one "modern",
>> one "old".
>
> I will be maintaining two code paths anyway.
>
> I'm hoping the old code path won't need much attention.
>
> The modern code path would be my new (personal) "standard" of developing modules. A refactor if you will. On which I will build new functionality.
>
>
>> If your goal is to "push" organizations to upgrade their Perl by means
>> of CPAN modules, write a killer module, and *don't* have an alternative
>> "old style" version available.
>
> I'm working on that as well. :-) But I'm not abandoning my old distributions. Unless they really don't make sense anymore. For those distributions, there's backpan.
>
>
>>>> use if $]>= 5.010, 'My::Module::perl5010';
>>>> use if $]>= 5.012, 'My::Module::perl5012';
>>>> use if $]>= 5.014, 'My::Module::perl5014';
>>>> use if $]>= 5.016, 'My::Module::perl5016';
>>>
>>> Again, this causes all sorts of havoc on CPAN, when different distributions
>>> have the same package declarations internally.
>>
>> There's no different distributions. There's just one distribution
>> my-module-1234.5.67.tar.gz, which contains:
>> lib/My/Module.pm (anything not rewritten)
>> lib/My/Module/perl5010.pm (anything that requires 5.010)
>> lib/My/Module/perl5012.pm (anything that requires 5.012)
>> lib/My/Module/perl5014.pm (anything that requires 5.014)
>> lib/My/Module/perl5016.pm (anything that requires 5.016)
>
> This is effectively what I'm doing. But then at install time, rather than at compile time.
>
> But even that can cause confusion. On search.cpan.org you get to see the 0.13 version of the pod for Thread::Queue::Any 1.04 distribution, if clicked from the distribution page (http://search.cpan.org/~elizabeth/Thread-Queue-Any/ ). And that's even with a file that doesn't even have the .pm extension. Just the mere occurrence of a -package- statement in the code, seems to be enough.

But with his method you wouldn't get 2 different things with the same
package name. You'd have My::Module v1.2 which has all the
documentation, etc. Then you'd have My::Module::perl5010,
My::Module::perl5012, My::Module::perl5014, etc which could just export
everything into the My::Module namespace when My::Module is used.

Still seems like a lot of work to keep old versions happy. I'd much
rather see something like David Cantrell's cpXXXan be more common and
supported.

--
Michael Peters
Plus Three, LP

pagaltzis at gmx

May 30, 2012, 7:55 AM

Post #23 of 33 (162 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

* David Cantrell <david [at] cantrell> [2012-05-30 13:10]:
> On Tue, May 29, 2012 at 11:04:55AM +0200, Elizabeth Mattijsen wrote:
> > In the past years, Perl 5 has seen a lot of new features added to
> > the language. Some of these features I've been dying to be able to
> > use in my CPAN modules. But alas, if I use these new features, my
> > modules don't run on older versions of Perl anymore.
>
> This is why I wrote and maintain cpXXXan.
>
> If you're stuck on perl 5.6.2 for whatever reason, just use
> cp5.6.2an.barnyard.co.uk as your CPAN mirror, and you'll get the
> latest version of any distribution which passes its tests on 5.6.2.
> For example, you'll get DBI 1.604, because that's the last version to
> pass its tests.

You missed most of the point.

The question is whether a fit-for-5.6 version of the module can receive
fixes and see new releases independently of the regular development of
the fit-for-blead version.

That’s a very different problem than the one cpXXXan answers, namely the
need of users to say “give me the last version of Foo::Bar that worked
on 5.6”.

Liz is coming at it from the author side: how can she keep maintaining
the old-perl version of a module without being stuck on old-version perl
for enhancements of the module.

(Of course her proposal fits handily into your cpXXXan scheme insofar as
cp5.6an should simply pick up Liz’ new fit-for-5.6 “dual” releases with
no further changes to the cpXXXan system on your or the users’ end.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

mpeters at plusthree

May 30, 2012, 8:00 AM

Post #24 of 33 (161 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On 05/30/2012 10:55 AM, Aristotle Pagaltzis wrote:

> You missed most of the point.

I don't think he did.

> The question is whether a fit-for-5.6 version of the module can receive
> fixes and see new releases independently of the regular development of
> the fit-for-blead version.

Sure, just release a new 1.x version of your module that works for older
perls and then a new 2.x version of your module for newer perls and
cpXXXan will pick up which ones works for which versions of perl and
gives the right one to the right user.

--
Michael Peters
Plus Three, LP

kentfredric at gmail

May 30, 2012, 9:59 AM

Post #25 of 33 (163 views)
Permalink

Re: CPAN / new Perl 5 features / Perl upgrade conundrum [In reply to]

On 31 May 2012 00:04, Philippe Bruhat (BooK) <philippe.bruhat [at] free> wrote:
> And there probably could be a bunch of extra index files using that
> information to make indices of stuff "assumed to work" with Perl >= 5.xxx.
> And make the CPAN clients aware of that (via a CPAN::Common module?).
>

Well, the data is already there on metacpan, assuming module authors
bother to state perl version deps.

For instance, take this reasonably straight-forward script I threw
together. ( Could have used MetaCPAN::API, but instead I opted for
things you're more likely to have installed already )
https://gist.github.com/2837537

And it gives the reasonably useful output as follows:

{
"5.008001" => {
date => "2010-03-20T22:56:55",
download =>
"http://cpan.metacpan.org/authors/id/K/KR/KRAIH/Mojolicious-0.999924.tar.gz",
perl => 5.008001,
status => "backpan",
tests => { fail => 5, na => 0, pass => 173, unknown => 1 },
v => 0.999924,
},
"5.008007" => {
date => "2011-09-29T08:27:22",
download =>
"http://cpan.metacpan.org/authors/id/S/SR/SRI/Mojolicious-1.99.tar.gz",
perl => 5.008007,
status => "backpan",
tests => { fail => 108, na => 7, pass => 245, unknown => 1 },
v => 1.99,
},
"5.010001" => {
date => "2012-05-28T12:11:13",
download =>
"http://cpan.metacpan.org/authors/id/S/SR/SRI/Mojolicious-2.97.tar.gz",
perl => 5.010001,
status => "latest",
tests => { fail => 0, na => 0, pass => 32, unknown => 0 },
v => 2.97,
},
}

And this is the very basics of the start of supporting some "slotting"
mechanism, where the "slot" boundary is defined by the perl version.

Its plausible that an author could at some future time define a
metadata value , ie: x_slot: "maint" , x_slot: "bleed", which is an
arbitrary string thats to be constant for a given arbitrary "release
series", and then people can just request the latest version "in that
slot". ( ie: the latest release that had that x_slot value ).

Traditional index-based CPAN Indexing would then also, instead of
indexing a package, index a given slot of a package if a slot is
defined, so you could then plausibly release new releases of old
release series without everyone thinking these "recent" releases are
to be upgraded to if they're on a "bleed" release series already.

Its even conceivable you could request a specific release series from
your CPAN client , ie:

cpanm FooModule [at] slo=bleed
cpanm FooModule [at] slo=maint

* ( @key=value,[key=value,...] notation chosen because it allows other
sorts of selectors to be added in future )

And your cpan client could also then remember which release series you
chose and only upgrade to members of that release series by default in
future ( unless specified otherwise ).

--
kentnl

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads