-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Malformed version number string 2.7.5+ #79
Comments
@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. |
Here's the ticket I opened for the |
Wow, thanks for the supreme detail and investigation. I'll add the test and push, but probably not today (maybe later tonight...) |
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:
|
Ah. I didn't. Perhaps the chef spec task should call the berks task first? I'll give that a go. |
It probably could/should, unless there's a better way to setup/test a cookbook these days? |
Seems fine, I just overlooked it while poking around :). |
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 |
This ensures the cookbook is still usable even if the Python version string is not parsable by `Gem::Version`. This occurs with certain Debian/Ubuntu Python version strings like `2.7.1+`.
@jtimberman @schisamo Thank you both for reporting and submitting two different approaches to fixing this. @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. Thoughts? |
@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
The original 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 |
Has there been any progress on this? |
@dmerrick pushing an update this week |
Additionally catch ArgumentError; Fixes #79
Thanks to @jtimberman and @schisamo, we've got a few fixes in place for this. |
Thanks all! |
This ensures the cookbook is still usable even if the Python version string is not parsable by `Gem::Version`. This occurs with certain Debian/Ubuntu Python version strings like `2.7.1+`.
Environment
(what's the +? Read on...)
Problem
When loading the default attributes file, Chef raises with this lovely exception:
For some reason, a
+
was appended to the default version of Python in Debian "jessie" (testing).On Debian 7.2 (wheezy), this is not the case, so the error doesn't manifest itself.
Proposed Solution
A horrible
#gsub
could be sent to the python version attribute can be used to strip out the character(s) not allowed inGem::Version
comparison.The text was updated successfully, but these errors were encountered: