a question about gem's ~>

[Albert Schlef]

I have a question about RubyGems's "~>". Sorry for asking this here.
I've searched in their "manual", but it's like searching a needle in a
haystack.

My question is simple:

My gem works only on Ruby 1.8 (that is, it doesn't work on Ruby 1.9 (and
isn't supposed to)).

In my gem specification I have:

s.required_ruby_version = '~> 1.8'

Is this correct? Or do I have to write '~> 1.8.0' ?

Unfortunately, Ruby 1.9's 'gem' installs my gem. I want it to refuse to
do this. I suspect that's because '~> 1.8' includes all versions of Ruby
till 2.0 (not including).

So haw can I tell RubyGems that my gem is for 1.8 only?

 

[Rick DeNatale]

I have a question about RubyGems's "~>". Sorry for asking this here.
I've searched in their "manual", but it's like searching a needle in a
haystack.

My question is simple:

My gem works only on Ruby 1.8 (that is, it doesn't work on Ruby 1.9 (and
isn't supposed to)).

In my gem specification I have:

=A0s.required_ruby_version =3D '~> 1.8'

This says that the version must have a major version number of 1, and
a minor version number >=3D 8, so it will include 1.9.x

Is this correct? Or do I have to write '~> 1.8.0' ?

You need to specify some teeny version number. so

~> 1.8.0
or
~> 1.8.6

should work.

--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Eric Hodel]

I have a question about RubyGems's "~>". Sorry for asking this here.
I've searched in their "manual", but it's like searching a needle in a
haystack.

ri Gem::Version

ri Gem::Requirement

My question is simple:

My gem works only on Ruby 1.8 (that is, it doesn't work on Ruby 1.9 (and
isn't supposed to)).

In my gem specification I have:

s.required_ruby_version = '~> 1.8'

Is this correct? Or do I have to write '~> 1.8.0' ?

~> 1.8.0 is correct

 

[Richard Conroy]

[Note: parts of this message were removed to make it a legal post.]

Hijacking this question a little, but how can I tell from my program what
gems
and what versions of those gems it is using?

If I knew what my programs gem dependencies were, I think it would really
help
me out on some very nasty issues. Last week for instance, it took me a
couple
of hours of trial and error to get my heroku .gems manifest to match the gem
versions I was using in development.

 

[Ryan Davis]

=20
Hijacking this question a little, but how can I tell from my program = what
gems
and what versions of those gems it is using?
=20
If I knew what my programs gem dependencies were, I think it would = really
help
me out on some very nasty issues. Last week for instance, it took me a
couple
of hours of trial and error to get my heroku .gems manifest to match = the gem
versions I was using in development.

YOU don't know what gems YOUR code is using? Why not?

One thing that might help is to try out the isolate gem. You specify =
what gems your project needs and they're privately installed and only =
those private gems get used. I use it on all my rails projects (and gem =
projects) at work.

 

[Richard Conroy]

[Note: parts of this message were removed to make it a legal post.]

YOU don't know what gems YOUR code is using? Why not?

Is this meant to be easy to know? Sure I know when I explicitly use dust, or
sinatra or
Haml or whatever, but I can never be certain of the network of dependencies
that those other
gems use.

One thing that might help is to try out the isolate gem. You specify what
gems your project needs and they're privately installed and only those
private gems get used. I use it on all my rails projects (and gem projects)
at work.

To be clear, I see this issue when checking out code across multiple systems
which have
different gems and gem versions installed. More specifically this is a
thorny problem with
non-explicit gem use, like when I choose to use a gem which in turn has
other dependencies
and incompatibility between different versions of the gems.

Had a bit of trial and error last week when I had to update my .gems
manifest on Heroku to
use a later version of datamapper and its dependencies. If I could have seen
what gems &
gem versions my development system was using it could have made for a much
easier experience.

regards,
Richard

 

[Ryan Davis]

=20
Is this meant to be easy to know? Sure I know when I explicitly use = dust, or
sinatra or
Haml or whatever, but I can never be certain of the network of = dependencies
that those other
gems use.

Ah. well... rubygems handles the transitive closure of the dependencies. =
You should only specify the top level (real) dependencies for your =
project.

To be clear, I see this issue when checking out code across multiple = systems
which have
different gems and gem versions installed. More specifically this is a
thorny problem with
non-explicit gem use, like when I choose to use a gem which in turn = has
other dependencies
and incompatibility between different versions of the gems.

This is exactly the type of thing that isolate solves. It is perfectly =
reasonable to have isolate installed as the only global gem and each =
project uses isolate to declare their gem dependencies and they're all =
installed private to each project.

 

[Richard Conroy]

[Note: parts of this message were removed to make it a legal post.]

This is exactly the type of thing that isolate solves. It is perfectly
reasonable to have isolate installed as the only global gem and each project
uses isolate to declare their gem dependencies and they're all installed
private to each project.

I will look into isolate, though the problem I face isn't due to
production/professional environments.

I often evaluate different gems or run through example code as part of
course work or general curiosity.
Sometimes I settle on a solution that I take further on, and its usually at
that stage that I need to figure
out exact gem dependencies. I often end up being shanghaied into helping out
someone else's ruby
problem as well. The messiest issues are always gem related.

I was just curious if there was a mechanism to inspect the loaded gems from
an application (and their
versions). Even unusual techniques, like perhaps objectspace inspection, or
reopening gem specific
methods.

Just curious if anyone knew any techniques.

 

[Eric Hodel]

I often evaluate different gems or run through example code as part of
course work or general curiosity.
Sometimes I settle on a solution that I take further on, and its = usually at
that stage that I need to figure
out exact gem dependencies. I often end up being shanghaied into = helping out
someone else's ruby
problem as well. The messiest issues are always gem related.
=20
I was just curious if there was a mechanism to inspect the loaded gems = from
an application (and their
versions). Even unusual techniques, like perhaps objectspace = inspection, or
reopening gem specific
methods.

ri Gem.loaded_specs=

 

[Richard Conroy]

[Note: parts of this message were removed to make it a legal post.]

ri Gem.loaded_specs

Thanks! Exactly what I wanted!