Comments (14)
cpanm just uses CMR, I think? EUMM does the s///, then passes it to CMR. Not sure what CPAN.pm does (it definitely strips, but I dunno if it uses CMR or its own code still)
from cpan-meta-requirements.
is this related to #26?
If so, stripping alpha-ness from $VERSION
will make a false requirement that passes in CMR's accepts_module()
but will fail on runtime. (See the issue linked above)
I usually don't lurk on #distzilla so a summary for that, or a specific problem that you need to address with an actual failing example, would be helpful for me to complete the context.
also - yes, cpanm uses CMR, hence miyagawa/cpanminus/issues/463 and #26
from cpan-meta-requirements.
Yes. I don't understand the (presumably failing?) example in #26 though; can someone clarify?
from cpan-meta-requirements.
suppose you have installed a dev version of Foo 2.000_001 from CPAN.
package Foo;
our $VERSION = '2.000_001';
and your code has a requirement for Foo => 2.000001
.
This issue is about making that requirement pass, by eliminating _
before comparison inside CMR.
That's fine until in the runtime you have a code that says:
use Foo 2.000001;
at this point perl will blow up: Foo version 2.000001 required--this is only version 2.000_001
.
from cpan-meta-requirements.
That's fine until in the runtime you have a code that says:
use Foo 2.000001;
at this point perl will blow up: Foo version 2.000001 required--this is only version 2.000_001.
We covered that in the #distzilla discussion -- the conclusion was basically
"we shouldn't have to support authors who do that, because that's dreadfully
wrong -- therefore the authors can keep both halves."
That is -- any author that declares an underscore version but doesn't include a follow-up line $VERSION = eval $VERSION;
is being naughty and wrong.
from cpan-meta-requirements.
"we shouldn't have to support authors who do that, because that's dreadfully wrong -- therefore the authors can keep both halves.
Well, it's not just "authors" who does this - it could be an end user, or a tool (a la PrereqScanner, cpanfile, Module::Metadata) that programatically ends up calling module->VERSION(requirement)
.
I honestly don't have a strong preference, but just wanted to point out that this issue contains an incorrect assumption (which you've covered as a wrong usage, just fine) and will possibly lead to a technical debt.
from cpan-meta-requirements.
I think you misunderstood. It's only authors that are declaring $VERSIONs with an underscore but neglecting the eval
line -- that's the bad bit. There's nothing wrong with calling ->VERSION
on any module, whether or not it's a trial release.
from cpan-meta-requirements.
There's nothing wrong with calling ->VERSION on any module, whether or not it's a trial release.
But it's not OK to call, if the installed version is a devel release and there's no eval
by the author.
The end result of this is that, as an end user, even if you have requires => { Foo => "2.001" }
in your requirement, you're not sure if you can safely call Foo->VERSION(2.001)
, depending on the dev/trial state.
from cpan-meta-requirements.
But it's not OK to call, if the installed version is a devel release and there's no eval by the author.
Why is that relevant for this discussion? It's not safe to call today if there's no eval by the author. The breakage isn't made worse, and the code was just as wrong yesterday as it is today.
from cpan-meta-requirements.
Why is that relevant for this discussion? It's not safe to call today if there's no eval by the author.
Sure, but you do know that it's not safe, because tools (i.e. cpanm or CPAN::Meta::Requirements) tells you that the installed version doesn't satisfy your requirement before running that code.
from cpan-meta-requirements.
I'm merely pointing out that, by accepting this change, there'll be a mismatch in a list of prereqs and runtime perl's UNIVERSAL:::VERSION behavior. i.e. if a user installs a dev version of the module, the user can't specifically require that version.
If we all think that is a use case that can be ignored, and using a module with use Module VER
with the version number that only exists as a dev version is un-supported, I'm fine.
cc @dagolden because you pointed out that fact in #26
from cpan-meta-requirements.
Here's a convoluted scenario:
- Author A uploads Foo-2.0_1 (dev) to CPAN
- User X installs Foo-2.0_1 with --dev
- Author A re-uploads Foo-2.01 (non-dev) to CPAN. It gets indexed
- Author B uploads Bar, with a prereq Foo => 2.01
- User X installs Bar
Today, because '2.0_1' doesn't satisfy the requirement '2.01' cpanm will try to upgrade to the "non-dev" version of Foo. With this change, cpanm will fail to upgrade it because '2.0_1' will now satisfy '2.01'. In addition a runtime call of use Foo 2.01
will fail.
Again, this is convoluted, and it must be an author A's fault of reusing the same version number in non-dev and dev. Just wanted to point out that, by accepting this change we're deprecating the currently supported scenario.
Look, I'm the one who requested this first in #26 :)
from cpan-meta-requirements.
I'd rather fix this in version.pm
from cpan-meta-requirements.
I'd rather fix this in version.pm
Me too. But can we do both? I suspect the CMR fix will be faster to implement, so it can at least move the problem one layer lower while we fret with what to change in version.pm.
from cpan-meta-requirements.
Related Issues (20)
- add \%options optional param to f_s_h
- coerce undef/zero-length versions to 0 in a_s_r
- "0.00" and "!= 0.00" now simplified as "0" and "!= 0" respectively. HOT 8
- Wrong CPAN::Meta::Requirements version HOT 4
- Publicize Range classes and objects HOT 2
- Explode @DAGOLDEN bundle in dist.ini HOT 7
- Descriptive error messages (hopefully an object!) to get which package gives conflicts HOT 4
- Ignore alpha in version comparison HOT 2
- Does 0.8.0 really not fulfil ">=0.6" ? HOT 8
- Bad handling of small fractional numeric versions HOT 3
- Throws exception on lax version HOT 2
- Version string normalization destroys alpha version info HOT 14
- Remove the use of Carp::confess HOT 1
- test errors on 5.6 HOT 2
- Feature: Add support for requirements in the form of PackageURLs (purls) HOT 22
- Wrong installation into site on 5.8.9 [rt.cpan.org #88141] HOT 2
- version::vpp can't handle literal v-strings less than 3 chars HOT 1
- block a range of versions via '<=' and '>='
- add $name as optional param to bad_version_hook
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cpan-meta-requirements.