A question about gem's ~>

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?

On Sun, Mar 28, 2010 at 7:21 PM, Albert S. [email protected]
wrote:

s.required_ruby_version = ‘~> 1.8’

This says that the version must have a major version number of 1, and
a minor version number >= 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.


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

On Mar 28, 2010, at 16:21, Albert S. wrote:

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

On Thu, Apr 1, 2010 at 4:16 AM, Eric H. [email protected] wrote:

On Mar 28, 2010, at 16:21, Albert S. wrote:

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.

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.

On Mar 31, 2010, at 20:27 , Richard C. wrote:

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.

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.

On Thu, Apr 1, 2010 at 4:44 AM, Ryan D. [email protected]
wrote:

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

On Thu, Apr 1, 2010 at 7:28 AM, Ryan D. [email protected]
wrote:

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.

On Mar 31, 2010, at 21:57 , Richard C. wrote:

On Thu, Apr 1, 2010 at 4:44 AM, Ryan D. [email protected] wrote:

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.

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

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.

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.

On Thu, Apr 1, 2010 at 9:17 AM, Eric H. [email protected] wrote:

ri Gem.loaded_specs

Thanks! Exactly what I wanted!

On Apr 1, 2010, at 00:21, Richard C. wrote:

versions). Even unusual techniques, like perhaps objectspace inspection, or
reopening gem specific
methods.

ri Gem.loaded_specs

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs