Bug & Fix: Illformed requirement ["/Users/somebody"]

[kematzy]

When trying out dependencies on a Sinatra project on OS X Leopard with Rubygems 1.3.4 and stock Ruby (1.8.6) installed I encountered this error when doing ' $ dep vendor --all ':

inside  vendor
  run    gem unpack rspec -v ~> 1.2.8 from "./vendor"
ERROR:  While executing gem ... (ArgumentError)
  Illformed requirement ["/Users/kematzy"]
  remove    vendor/rspec/.git

The error is due to the ~> string which is used in the dependencies file declaration.

If you use >= instead it works.

The code fix is: bin/dep line 54

run "gem unpack #{dep.name} -v #{dep.version}"

change to

run "gem unpack #{dep.name} -v #{dep.version.gsub('~>','>=').gsub('~<','<=')}" # hack

Didn't take the time to figure out a better place to fix this, but it fixes the problem on my system at least.

You might also want to change the README where I copied the faulty syntax from.

[djanowski]

It works but it's not exactly the same...

BTW, what skeleton are you using? The default one doesn't use RSpec... (and I don't see a big advantage of using ~> with a revision release like 1.2.8)

[kematzy]

Hi,

The issue is that " $ dep vendor --all " fails when you use the "~>" syntax, on the above setup. I don't know why that is. All I'm reporting is that it fails, and the syntax should (?) be using ">=" or "<=" rather than "~>" or "~<" .

The issue has nothing to do with RSpec or the skeleton I'm using at all. RSpec just happened to be the gem that failed first in the list.

On Mac OS X (10.5 & 10.6) with Rubygems 1.3.4/5 and default Ruby installed the following command:

gem unpack NAME_OF_GEM -v ~> VERSION

fails, whereas this command:

gem unpack NAME_OF_GEM -v >= VERSION

works.

I hope I made my point clear enough. Please test on your system, and if ~> works there, then please make a note in the README to inform OS X users about the issue. Hopefully they won't have to waste time on understanding why it fails and coming up with a fix for it.

Secondly. What is the difference between ~> and >= ? I can see it semantically, but in real usage I can't think of one.

Thirdly, I'm not actually using a skeleton, but rather Rubigen generators. The main reason being that I haven't worked out how to add a "skeleton" within another "skeleton". But that's another issue ;)

[djanowski]

I understand what the issue is. I was just saying that the "fix" is not really a fix. I agree we should inform users that currently you can't vendor if the dependency is expressed with ~>.

Thinking in RubyGems terms, I think ~> is a nice feature. It allows me to be optimistic and express my dependency like "~> 2.0" so that all 2.0.1, 2.0.2 etc will work, but the dependency is not met by 3.0. (Of course I like SHA1 more, but for those who like RubyGems, it's a nice thing).

So if we simply "replace" ~> for =>, the dependency may not be met (if, say, version 3.0 is out already).

Forgive me for asking about skeletons. I was applying Monk patches at 12.30am and didn't notice the issue you reported was on Dependencies :)

[paulwalker]

What about putting single quotes around the version? Also, jruby -S dep... does not run the command under jruby when both mri and jvm versions are installed.

[djanowski]

That's right, quoting the version does the trick. If you have some spare minutes I'd happily apply the patch.

I don't use JRuby myself, so I'd need you to test that if you're interested.

[paulwalker]

To follow up on JRuby, I found the following fix worked in bin/dep

def gem_cmd
  @gem_cmd ||= Gem.platforms.last.os == "java" ? 'jgem' : 'gem'
end

def fetch(dep)
  if dep.version
    run "#{gem_cmd} unpack #{dep.name} -v '#{dep.version}'"
  else
    run "git clone #{dep.url} #{dep.name} -q --depth 1"
  end
end