Prev: divide BMP to YUV channels
Next: [ANN] Free public beta of memprof.com the ruby memory analyzer
From: Albert Schlef on 28 Mar 2010 19:21
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?
--
Posted via http://www.ruby-forum.com/.

From: Rick DeNatale on 28 Mar 2010 20:35
On Sun, Mar 28, 2010 at 7:21 PM, Albert Schlef <albertschlef(a)gmail.com> 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.
>
> 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'

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

From: Ryan Davis on 31 Mar 2010 23:44

On Mar 31, 2010, at 20:27 , Richard Conroy wrote:

> On Thu, Apr 1, 2010 at 4:16 AM, Eric Hodel <drbrain(a)segment7.net> wrote:
>
>> On Mar 28, 2010, at 16:21, Albert Schlef 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.

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.


From: Eric Hodel on 1 Apr 2010 04:17
On Apr 1, 2010, at 00:21, Richard Conroy wrote:

> 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.

ri Gem.loaded_specs
From: Ryan Davis on 1 Apr 2010 02:28

On Mar 31, 2010, at 21:57 , Richard Conroy wrote:

> On Thu, Apr 1, 2010 at 4:44 AM, Ryan Davis <ryand-ruby(a)zenspider.com> 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.


 |  Next  |  Last
Pages: 1 2
Prev: divide BMP to YUV channels
Next: [ANN] Free public beta of memprof.com the ruby memory analyzer