Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Malformed version number string 2.7.5+ #79
(what's the +? Read on...)
When loading the default attributes file, Chef raises with this lovely exception:
For some reason, a
On Debian 7.2 (wheezy), this is not the case, so the error doesn't manifest itself.
@jtimberman Thanks for surfacing this issue.
Here's a few things:
I agree that the solution proposed in #80 will fix your specific use case, but that's patching code for general use that may not solve things for others - I'd rather get to the bottom of this and get it fixed at the root cause.
In general, working with a testing distribution may produce these kinds of bugs, so it's on you for using something that cutting edge.
Looking at the internals of the Debian package source, I couldn't really find where that string would be represented as such, so it's pretty confusing to me why this would report such.
I'm trying to run the specs and getting this error:
I run rspec directly (against the spec dir, rather than the dir in the Rakefile), and all the specs fail (except the one that checks the default recipe does nothing)
Aw, phooey. A couple of questions:
I just hit this issue on an Ubuntu 11.04 box in our CI infrastructure :(
Maybe we should use an alternate version string parser (vs
@schisamo On the one hand, I'd love to have a widely-distributed method for parsing version strings readily available within a given Chef run, so I wouldn't have to drag any more in (versionomy, mixlib-versioning, etc).
That doesn't solve the basic problem that the string
I think @jtimberman's solution to strip off anything after the Version is a good place to go - as it continues to ensure that there's a valid version of Python installed.
Will the ArgumentError catch if no python is available? That's rare, sure, but possible, and at that point, I think we'd rather fail than warn.
@miketheman Both approaches will get the job done, I just don't like the idea of introducing additional parsing logic or regexes that could continue to break. My approach (catching
IMO this sort of logic belongs in a recipe. This would allow the Python version string parsing logic to only get exercised if a user didn't override