Discussion:
Perl::MinimumVersion
Adam Kennedy
2005-04-16 09:06:36 UTC
Permalink
Hi folks

I'm presuming all of you have had a chance to read Rob's perl.com article.

http://www.perl.com/pub/a/2005/04/14/cpan_guidelines.html

I for one noticed a few interesting/odd points. :)

Firstly, I disagree with Rob's idea of excluding all operating systems
until you get reports from users. Most of the time, 90% of people don't
report. They just don't use the module.

Better in my mind to ship anyway, but make sure your tests relating to
the filesystem are extra paranoid. That way modules just simply fail to
install on unusual things like VMS.

But what I most wanted to speak about was minimum Perl versions for
code, relating his Rob's "gotchas" stuff.

It should be possible (and it's been in the mental roadmap for a long
time) to create with PPI a package that can tell you what the minimum
version of Perl is to run any chunk of Perl code.

All the module would need to be would be a collection of PPI &wanted
functions which search for a particular thing...

sub has_our_variables {
$_[1]->isa('PPI::Statement::Variable')
and $_[1]->type eq 'our';
}

sub has_use_warnings {
$_[1]->isa('PPI::Statement::Include')
and $_[1]->pragma eq 'warnings';
}

... and a small register mapping each feature detector to the version in
which it first appeared.

my %register = (
has_our_variables => '5.6.0',
has_use_warnings => '5.6.0',
etc...
);

To find the minimum version you simple run some sort of...

# (pseudocode)
$Document = PPI::Document->load( file );
@versions = grep { $Document->find_any(function) } %register;

Then find the maximum version, and you've got your "required Perl
version" for each bit of Perl.

Of course, there's some WAY more efficient algorithms I can see for
speeding up the searching, and you would also have to trace down into
included modules, but the above would get you a "naive minimum version",
which you would then compared against the same for all the needed modules.

I keep meaning to get around to just implementing it, but I'm stretched
for time as it is...

Rob, anyone? Interested? :)

Adam K
Rhesa
2005-04-16 10:43:09 UTC
Permalink
Post by Adam Kennedy
Hi folks
I'm presuming all of you have had a chance to read Rob's perl.com article.
http://www.perl.com/pub/a/2005/04/14/cpan_guidelines.html
I for one noticed a few interesting/odd points. :)
[...]
Post by Adam Kennedy
But what I most wanted to speak about was minimum Perl versions for
code, relating his Rob's "gotchas" stuff.
It should be possible (and it's been in the mental roadmap for a long
time) to create with PPI a package that can tell you what the minimum
version of Perl is to run any chunk of Perl code.
That would be an excellent tool.
I just published my first module on CPAN, and this was my biggest issue. I _know_ it could be made to run on perl 5.004, with DBI 1.06, but
I have no experience whatsoever with perls before 5.6.0. Knowing all the gotcha's would be great!

[snip]
Post by Adam Kennedy
Of course, there's some WAY more efficient algorithms I can see for
speeding up the searching, and you would also have to trace down into
included modules, but the above would get you a "naive minimum version",
which you would then compared against the same for all the needed modules.
Efficiency apart, how would you deal with finding the minimum required dependent modules?
Say my PREREQ asks for DBI => 1.06, but I have 1.42 installed. Would you go find DBI 1.06 and check that, or use the installed version?
I'm getting chills down my spine just contemplating that being done recursively.
Post by Adam Kennedy
I keep meaning to get around to just implementing it, but I'm stretched
for time as it is...
I'd be happy to just see a list of compatibility notes. But some sort of parser would be extremely cool.

Rhesa
Adam Kennedy
2005-04-16 17:54:57 UTC
Permalink
You pretty much have to work with the current versions of modules for
most situations, as anyone using CPAN/CPANPLUS is going to have their
modules updated. Or at least, that gets you to version 1.0 of the module.

You also have to ignore perl version stuff for anything that is core on
whatever the current Perl is. The logic isn't too hard, and
Module::CoreList is handy in this regard.

For starters, I'd just check what's on the current system. Most modules
don't change their perl version deps very often.

Adam K
Post by Adam Kennedy
Post by Adam Kennedy
Hi folks
I'm presuming all of you have had a chance to read Rob's perl.com
article.
Post by Adam Kennedy
http://www.perl.com/pub/a/2005/04/14/cpan_guidelines.html
I for one noticed a few interesting/odd points. :)
[...]
Post by Adam Kennedy
But what I most wanted to speak about was minimum Perl versions for
code, relating his Rob's "gotchas" stuff.
It should be possible (and it's been in the mental roadmap for a long
time) to create with PPI a package that can tell you what the minimum
version of Perl is to run any chunk of Perl code.
That would be an excellent tool.
I just published my first module on CPAN, and this was my biggest issue.
I _know_ it could be made to run on perl 5.004, with DBI 1.06, but I
have no experience whatsoever with perls before 5.6.0. Knowing all the
gotcha's would be great!
[snip]
Post by Adam Kennedy
Of course, there's some WAY more efficient algorithms I can see for
speeding up the searching, and you would also have to trace down into
included modules, but the above would get you a "naive minimum version",
which you would then compared against the same for all the needed
modules.
Efficiency apart, how would you deal with finding the minimum required dependent modules?
Say my PREREQ asks for DBI => 1.06, but I have 1.42 installed. Would you
go find DBI 1.06 and check that, or use the installed version?
I'm getting chills down my spine just contemplating that being done recursively.
Post by Adam Kennedy
I keep meaning to get around to just implementing it, but I'm stretched
for time as it is...
I'd be happy to just see a list of compatibility notes. But some sort of
parser would be extremely cool.
Rhesa
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
Rob Kinyon
2005-04-17 18:55:56 UTC
Permalink
I would ignore the modules for now. Instead, focus on the language
features you use, like "our", 3-arg open, etc. Then, you can declare
"I am Perl#.#.# compliant.". Then, when someone wants to figure out if
a given module can be run on Perl #.#.#, they can look at the module
version they want and all the dependent modules, then take the largest
Perl version among them as the minimum version the module (and its
dependencies) will work on.

Remember - 1.0 could run on 5.004, 1.1 on 5.6.0, and 1.2 on 5.004. So,
it's like looking at

SELECT MAX(perl_version)
FROM some_master_table
WHERE module_version >= ?
AND module_name = ?

This can also allow the power user to choose to downgrade a given
module in order to support a lower Perl version. Now, I don't think
that feature will be used more than 10 times in the future history of
Perl, but it's nice to know it's in your back pocket ... if you need
it. :-)

Rob
Post by Adam Kennedy
You pretty much have to work with the current versions of modules for
most situations, as anyone using CPAN/CPANPLUS is going to have their
modules updated. Or at least, that gets you to version 1.0 of the module.
You also have to ignore perl version stuff for anything that is core on
whatever the current Perl is. The logic isn't too hard, and
Module::CoreList is handy in this regard.
For starters, I'd just check what's on the current system. Most modules
don't change their perl version deps very often.
Adam K
Post by Adam Kennedy
Post by Adam Kennedy
Hi folks
I'm presuming all of you have had a chance to read Rob's perl.com
article.
Post by Adam Kennedy
http://www.perl.com/pub/a/2005/04/14/cpan_guidelines.html
I for one noticed a few interesting/odd points. :)
[...]
Post by Adam Kennedy
But what I most wanted to speak about was minimum Perl versions for
code, relating his Rob's "gotchas" stuff.
It should be possible (and it's been in the mental roadmap for a long
time) to create with PPI a package that can tell you what the minimum
version of Perl is to run any chunk of Perl code.
That would be an excellent tool.
I just published my first module on CPAN, and this was my biggest issue.
I _know_ it could be made to run on perl 5.004, with DBI 1.06, but I
have no experience whatsoever with perls before 5.6.0. Knowing all the
gotcha's would be great!
[snip]
Post by Adam Kennedy
Of course, there's some WAY more efficient algorithms I can see for
speeding up the searching, and you would also have to trace down into
included modules, but the above would get you a "naive minimum version",
which you would then compared against the same for all the needed
modules.
Efficiency apart, how would you deal with finding the minimum required
dependent modules?
Say my PREREQ asks for DBI => 1.06, but I have 1.42 installed. Would you
go find DBI 1.06 and check that, or use the installed version?
I'm getting chills down my spine just contemplating that being done recursively.
Post by Adam Kennedy
I keep meaning to get around to just implementing it, but I'm stretched
for time as it is...
I'd be happy to just see a list of compatibility notes. But some sort of
parser would be extremely cool.
Rhesa
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
Rob Kinyon
2005-04-19 18:00:28 UTC
Permalink
We might want to get going with this ...

http://www.perlmonks.org/?node_id=449344
Post by Rob Kinyon
I would ignore the modules for now. Instead, focus on the language
features you use, like "our", 3-arg open, etc. Then, you can declare
"I am Perl#.#.# compliant.". Then, when someone wants to figure out if
a given module can be run on Perl #.#.#, they can look at the module
version they want and all the dependent modules, then take the largest
Perl version among them as the minimum version the module (and its
dependencies) will work on.
Remember - 1.0 could run on 5.004, 1.1 on 5.6.0, and 1.2 on 5.004. So,
it's like looking at
SELECT MAX(perl_version)
FROM some_master_table
WHERE module_version >= ?
AND module_name = ?
This can also allow the power user to choose to downgrade a given
module in order to support a lower Perl version. Now, I don't think
that feature will be used more than 10 times in the future history of
Perl, but it's nice to know it's in your back pocket ... if you need
it. :-)
Rob
Post by Adam Kennedy
You pretty much have to work with the current versions of modules for
most situations, as anyone using CPAN/CPANPLUS is going to have their
modules updated. Or at least, that gets you to version 1.0 of the module.
You also have to ignore perl version stuff for anything that is core on
whatever the current Perl is. The logic isn't too hard, and
Module::CoreList is handy in this regard.
For starters, I'd just check what's on the current system. Most modules
don't change their perl version deps very often.
Adam K
Post by Adam Kennedy
Post by Adam Kennedy
Hi folks
I'm presuming all of you have had a chance to read Rob's perl.com
article.
Post by Adam Kennedy
http://www.perl.com/pub/a/2005/04/14/cpan_guidelines.html
I for one noticed a few interesting/odd points. :)
[...]
Post by Adam Kennedy
But what I most wanted to speak about was minimum Perl versions for
code, relating his Rob's "gotchas" stuff.
It should be possible (and it's been in the mental roadmap for a long
time) to create with PPI a package that can tell you what the minimum
version of Perl is to run any chunk of Perl code.
That would be an excellent tool.
I just published my first module on CPAN, and this was my biggest issue.
I _know_ it could be made to run on perl 5.004, with DBI 1.06, but I
have no experience whatsoever with perls before 5.6.0. Knowing all the
gotcha's would be great!
[snip]
Post by Adam Kennedy
Of course, there's some WAY more efficient algorithms I can see for
speeding up the searching, and you would also have to trace down into
included modules, but the above would get you a "naive minimum version",
which you would then compared against the same for all the needed
modules.
Efficiency apart, how would you deal with finding the minimum required
dependent modules?
Say my PREREQ asks for DBI => 1.06, but I have 1.42 installed. Would you
go find DBI 1.06 and check that, or use the installed version?
I'm getting chills down my spine just contemplating that being done recursively.
Post by Adam Kennedy
I keep meaning to get around to just implementing it, but I'm stretched
for time as it is...
I'd be happy to just see a list of compatibility notes. But some sort of
parser would be extremely cool.
Rhesa
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
Adam Kennedy
2005-04-20 00:29:21 UTC
Permalink
I've got a basic first version (that ONLY checks for the use of 'our')
done and sitting here. If anyone wants to help with some quick tests or
something, I'll check it into the Parse::Perl sourceforce CVS.

Accounts are available for anyone that wants one.

Adam K
Post by Rob Kinyon
We might want to get going with this ...
http://www.perlmonks.org/?node_id=449344
Post by Rob Kinyon
I would ignore the modules for now. Instead, focus on the language
features you use, like "our", 3-arg open, etc. Then, you can declare
"I am Perl#.#.# compliant.". Then, when someone wants to figure out if
a given module can be run on Perl #.#.#, they can look at the module
version they want and all the dependent modules, then take the largest
Perl version among them as the minimum version the module (and its
dependencies) will work on.
Remember - 1.0 could run on 5.004, 1.1 on 5.6.0, and 1.2 on 5.004. So,
it's like looking at
SELECT MAX(perl_version)
FROM some_master_table
WHERE module_version >= ?
AND module_name = ?
This can also allow the power user to choose to downgrade a given
module in order to support a lower Perl version. Now, I don't think
that feature will be used more than 10 times in the future history of
Perl, but it's nice to know it's in your back pocket ... if you need
it. :-)
Rob
Post by Adam Kennedy
You pretty much have to work with the current versions of modules for
most situations, as anyone using CPAN/CPANPLUS is going to have their
modules updated. Or at least, that gets you to version 1.0 of the module.
You also have to ignore perl version stuff for anything that is core on
whatever the current Perl is. The logic isn't too hard, and
Module::CoreList is handy in this regard.
For starters, I'd just check what's on the current system. Most modules
don't change their perl version deps very often.
Adam K
Post by Adam Kennedy
Post by Adam Kennedy
Hi folks
I'm presuming all of you have had a chance to read Rob's perl.com
article.
Post by Adam Kennedy
http://www.perl.com/pub/a/2005/04/14/cpan_guidelines.html
I for one noticed a few interesting/odd points. :)
[...]
Post by Adam Kennedy
But what I most wanted to speak about was minimum Perl versions for
code, relating his Rob's "gotchas" stuff.
It should be possible (and it's been in the mental roadmap for a long
time) to create with PPI a package that can tell you what the minimum
version of Perl is to run any chunk of Perl code.
That would be an excellent tool.
I just published my first module on CPAN, and this was my biggest issue.
I _know_ it could be made to run on perl 5.004, with DBI 1.06, but I
have no experience whatsoever with perls before 5.6.0. Knowing all the
gotcha's would be great!
[snip]
Post by Adam Kennedy
Of course, there's some WAY more efficient algorithms I can see for
speeding up the searching, and you would also have to trace down into
included modules, but the above would get you a "naive minimum version",
which you would then compared against the same for all the needed
modules.
Efficiency apart, how would you deal with finding the minimum required
dependent modules?
Say my PREREQ asks for DBI => 1.06, but I have 1.42 installed. Would you
go find DBI 1.06 and check that, or use the installed version?
I'm getting chills down my spine just contemplating that being done recursively.
Post by Adam Kennedy
I keep meaning to get around to just implementing it, but I'm stretched
for time as it is...
I'd be happy to just see a list of compatibility notes. But some sort of
parser would be extremely cool.
Rhesa
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
Adam Kennedy
2005-04-20 04:58:27 UTC
Permalink
Okie dokey

I've just uploaded Perl::MinimumVersion 0.01 to PAUSE, it should be
visible on CPAN in a few hours.

It works fine, and uses all the properly optimized algorithms, but
doesn't check for very many things.

So if you know of any specific syntax things that require a perl
version, you are more than welcome to cut and paste an existing check
function and modify the 2 or 3 lines of code needed.

Then just post it to RT with the version for that check, and I'll merge
whatever comes in.

Or if you have been added to the Parse::Perl soureforge project, just go
straight ahead and add whatever functions you want.

Adam K
Post by Adam Kennedy
I've got a basic first version (that ONLY checks for the use of 'our')
done and sitting here. If anyone wants to help with some quick tests or
something, I'll check it into the Parse::Perl sourceforce CVS.
Accounts are available for anyone that wants one.
Adam K
Post by Rob Kinyon
We might want to get going with this ...
http://www.perlmonks.org/?node_id=449344
Post by Rob Kinyon
I would ignore the modules for now. Instead, focus on the language
features you use, like "our", 3-arg open, etc. Then, you can declare
"I am Perl#.#.# compliant.". Then, when someone wants to figure out if
a given module can be run on Perl #.#.#, they can look at the module
version they want and all the dependent modules, then take the largest
Perl version among them as the minimum version the module (and its
dependencies) will work on.
Remember - 1.0 could run on 5.004, 1.1 on 5.6.0, and 1.2 on 5.004. So,
it's like looking at
SELECT MAX(perl_version)
FROM some_master_table
WHERE module_version >= ?
AND module_name = ?
This can also allow the power user to choose to downgrade a given
module in order to support a lower Perl version. Now, I don't think
that feature will be used more than 10 times in the future history of
Perl, but it's nice to know it's in your back pocket ... if you need
it. :-)
Rob
Post by Adam Kennedy
You pretty much have to work with the current versions of modules for
most situations, as anyone using CPAN/CPANPLUS is going to have their
modules updated. Or at least, that gets you to version 1.0 of the module.
You also have to ignore perl version stuff for anything that is core on
whatever the current Perl is. The logic isn't too hard, and
Module::CoreList is handy in this regard.
For starters, I'd just check what's on the current system. Most modules
don't change their perl version deps very often.
Adam K
Post by Adam Kennedy
Post by Adam Kennedy
Hi folks
I'm presuming all of you have had a chance to read Rob's perl.com
article.
Post by Adam Kennedy
http://www.perl.com/pub/a/2005/04/14/cpan_guidelines.html
I for one noticed a few interesting/odd points. :)
[...]
Post by Adam Kennedy
But what I most wanted to speak about was minimum Perl versions for
code, relating his Rob's "gotchas" stuff.
It should be possible (and it's been in the mental roadmap for a
long
Post by Adam Kennedy
time) to create with PPI a package that can tell you what the
minimum
Post by Adam Kennedy
version of Perl is to run any chunk of Perl code.
That would be an excellent tool.
I just published my first module on CPAN, and this was my biggest issue.
I _know_ it could be made to run on perl 5.004, with DBI 1.06, but I
have no experience whatsoever with perls before 5.6.0. Knowing all the
gotcha's would be great!
[snip]
Post by Adam Kennedy
Of course, there's some WAY more efficient algorithms I can see for
speeding up the searching, and you would also have to trace down
into
Post by Adam Kennedy
included modules, but the above would get you a "naive minimum
version",
Post by Adam Kennedy
which you would then compared against the same for all the needed
modules.
Efficiency apart, how would you deal with finding the minimum required
dependent modules?
Say my PREREQ asks for DBI => 1.06, but I have 1.42 installed. Would you
go find DBI 1.06 and check that, or use the installed version?
I'm getting chills down my spine just contemplating that being done recursively.
Post by Adam Kennedy
I keep meaning to get around to just implementing it, but I'm
stretched
Post by Adam Kennedy
for time as it is...
I'd be happy to just see a list of compatibility notes. But some sort of
parser would be extremely cool.
Rhesa
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
Rob Kinyon
2005-04-26 13:27:49 UTC
Permalink
Adam -

castaway on PM just ran into an issue with Module::ScanDeps not
handling conditional requires within eval blocks correctly. This
sounds like a place for PPI (cause M::SD currently parses Perl itself,
very naively). But, I think Autrijus is a little busy right now. So,
just thought I'd propose it to you ...

Rob
Post by Adam Kennedy
Okie dokey
I've just uploaded Perl::MinimumVersion 0.01 to PAUSE, it should be
visible on CPAN in a few hours.
It works fine, and uses all the properly optimized algorithms, but
doesn't check for very many things.
So if you know of any specific syntax things that require a perl
version, you are more than welcome to cut and paste an existing check
function and modify the 2 or 3 lines of code needed.
Then just post it to RT with the version for that check, and I'll merge
whatever comes in.
Or if you have been added to the Parse::Perl soureforge project, just go
straight ahead and add whatever functions you want.
Adam K
Post by Adam Kennedy
I've got a basic first version (that ONLY checks for the use of 'our')
done and sitting here. If anyone wants to help with some quick tests or
something, I'll check it into the Parse::Perl sourceforce CVS.
Accounts are available for anyone that wants one.
Adam K
Post by Rob Kinyon
We might want to get going with this ...
http://www.perlmonks.org/?node_id=449344
Post by Rob Kinyon
I would ignore the modules for now. Instead, focus on the language
features you use, like "our", 3-arg open, etc. Then, you can declare
"I am Perl#.#.# compliant.". Then, when someone wants to figure out if
a given module can be run on Perl #.#.#, they can look at the module
version they want and all the dependent modules, then take the largest
Perl version among them as the minimum version the module (and its
dependencies) will work on.
Remember - 1.0 could run on 5.004, 1.1 on 5.6.0, and 1.2 on 5.004. So,
it's like looking at
SELECT MAX(perl_version)
FROM some_master_table
WHERE module_version >= ?
AND module_name = ?
This can also allow the power user to choose to downgrade a given
module in order to support a lower Perl version. Now, I don't think
that feature will be used more than 10 times in the future history of
Perl, but it's nice to know it's in your back pocket ... if you need
it. :-)
Rob
Post by Adam Kennedy
You pretty much have to work with the current versions of modules for
most situations, as anyone using CPAN/CPANPLUS is going to have their
modules updated. Or at least, that gets you to version 1.0 of the module.
You also have to ignore perl version stuff for anything that is core on
whatever the current Perl is. The logic isn't too hard, and
Module::CoreList is handy in this regard.
For starters, I'd just check what's on the current system. Most modules
don't change their perl version deps very often.
Adam K
Post by Adam Kennedy
Post by Adam Kennedy
Hi folks
I'm presuming all of you have had a chance to read Rob's perl.com
article.
Post by Adam Kennedy
http://www.perl.com/pub/a/2005/04/14/cpan_guidelines.html
I for one noticed a few interesting/odd points. :)
[...]
Post by Adam Kennedy
But what I most wanted to speak about was minimum Perl versions for
code, relating his Rob's "gotchas" stuff.
It should be possible (and it's been in the mental roadmap for a
long
Post by Adam Kennedy
time) to create with PPI a package that can tell you what the
minimum
Post by Adam Kennedy
version of Perl is to run any chunk of Perl code.
That would be an excellent tool.
I just published my first module on CPAN, and this was my biggest issue.
I _know_ it could be made to run on perl 5.004, with DBI 1.06, but I
have no experience whatsoever with perls before 5.6.0. Knowing all the
gotcha's would be great!
[snip]
Post by Adam Kennedy
Of course, there's some WAY more efficient algorithms I can see for
speeding up the searching, and you would also have to trace down
into
Post by Adam Kennedy
included modules, but the above would get you a "naive minimum
version",
Post by Adam Kennedy
which you would then compared against the same for all the needed
modules.
Efficiency apart, how would you deal with finding the minimum required
dependent modules?
Say my PREREQ asks for DBI => 1.06, but I have 1.42 installed. Would you
go find DBI 1.06 and check that, or use the installed version?
I'm getting chills down my spine just contemplating that being done
recursively.
Post by Adam Kennedy
I keep meaning to get around to just implementing it, but I'm
stretched
Post by Adam Kennedy
for time as it is...
I'd be happy to just see a list of compatibility notes. But some sort of
parser would be extremely cool.
Rhesa
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
Adam Kennedy
2005-04-27 02:55:13 UTC
Permalink
Yep, it is.

Ultimately, I think pretty much the entire Module:: namespace should end
up somewhat related to PPI eventually. But doing so it getting a bit out
of my league.

I'm also very busy for almost the entire period up until OSCON, so at
some point someone else is going to need to step up to help with these
PPI ports of the existing modules. :)

Adam K
Post by Rob Kinyon
Adam -
castaway on PM just ran into an issue with Module::ScanDeps not
handling conditional requires within eval blocks correctly. This
sounds like a place for PPI (cause M::SD currently parses Perl itself,
very naively). But, I think Autrijus is a little busy right now. So,
just thought I'd propose it to you ...
Rob
Post by Adam Kennedy
Okie dokey
I've just uploaded Perl::MinimumVersion 0.01 to PAUSE, it should be
visible on CPAN in a few hours.
It works fine, and uses all the properly optimized algorithms, but
doesn't check for very many things.
So if you know of any specific syntax things that require a perl
version, you are more than welcome to cut and paste an existing check
function and modify the 2 or 3 lines of code needed.
Then just post it to RT with the version for that check, and I'll merge
whatever comes in.
Or if you have been added to the Parse::Perl soureforge project, just go
straight ahead and add whatever functions you want.
Adam K
Post by Adam Kennedy
I've got a basic first version (that ONLY checks for the use of 'our')
done and sitting here. If anyone wants to help with some quick tests or
something, I'll check it into the Parse::Perl sourceforce CVS.
Accounts are available for anyone that wants one.
Adam K
Post by Rob Kinyon
We might want to get going with this ...
http://www.perlmonks.org/?node_id=449344
Post by Rob Kinyon
I would ignore the modules for now. Instead, focus on the language
features you use, like "our", 3-arg open, etc. Then, you can declare
"I am Perl#.#.# compliant.". Then, when someone wants to figure out if
a given module can be run on Perl #.#.#, they can look at the module
version they want and all the dependent modules, then take the largest
Perl version among them as the minimum version the module (and its
dependencies) will work on.
Remember - 1.0 could run on 5.004, 1.1 on 5.6.0, and 1.2 on 5.004. So,
it's like looking at
SELECT MAX(perl_version)
FROM some_master_table
WHERE module_version >= ?
AND module_name = ?
This can also allow the power user to choose to downgrade a given
module in order to support a lower Perl version. Now, I don't think
that feature will be used more than 10 times in the future history of
Perl, but it's nice to know it's in your back pocket ... if you need
it. :-)
Rob
Post by Adam Kennedy
You pretty much have to work with the current versions of modules for
most situations, as anyone using CPAN/CPANPLUS is going to have their
modules updated. Or at least, that gets you to version 1.0 of the module.
You also have to ignore perl version stuff for anything that is core on
whatever the current Perl is. The logic isn't too hard, and
Module::CoreList is handy in this regard.
For starters, I'd just check what's on the current system. Most modules
don't change their perl version deps very often.
Adam K
Post by Adam Kennedy
Post by Adam Kennedy
Hi folks
I'm presuming all of you have had a chance to read Rob's perl.com
article.
Post by Adam Kennedy
http://www.perl.com/pub/a/2005/04/14/cpan_guidelines.html
I for one noticed a few interesting/odd points. :)
[...]
Post by Adam Kennedy
But what I most wanted to speak about was minimum Perl versions for
code, relating his Rob's "gotchas" stuff.
It should be possible (and it's been in the mental roadmap for a
long
Post by Adam Kennedy
time) to create with PPI a package that can tell you what the
minimum
Post by Adam Kennedy
version of Perl is to run any chunk of Perl code.
That would be an excellent tool.
I just published my first module on CPAN, and this was my biggest issue.
I _know_ it could be made to run on perl 5.004, with DBI 1.06, but I
have no experience whatsoever with perls before 5.6.0. Knowing all the
gotcha's would be great!
[snip]
Post by Adam Kennedy
Of course, there's some WAY more efficient algorithms I can see for
speeding up the searching, and you would also have to trace down
into
Post by Adam Kennedy
included modules, but the above would get you a "naive minimum
version",
Post by Adam Kennedy
which you would then compared against the same for all the needed
modules.
Efficiency apart, how would you deal with finding the minimum required
dependent modules?
Say my PREREQ asks for DBI => 1.06, but I have 1.42 installed. Would you
go find DBI 1.06 and check that, or use the installed version?
I'm getting chills down my spine just contemplating that being done recursively.
Post by Adam Kennedy
I keep meaning to get around to just implementing it, but I'm
stretched
Post by Adam Kennedy
for time as it is...
I'd be happy to just see a list of compatibility notes. But some sort of
parser would be extremely cool.
Rhesa
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
Loading...