Gemfile.lock questions

[Dmitri Dolguikh]

On 12-05-31 6:10 PM, Jason Guiditta wrote:
> On 31/05/12 13:45 +0400, Dmitri Dolguikh wrote:
>>   On 12-05-31 6:52 AM, Michael Orazi wrote:
>>
>>
>> ----- Original Message -----
>>
>> On 24/04/12 21:20 +0300, Ohad Levy wrote:
>>
>> On 04/24/2012 04:26 AM, Jason Guiditta wrote:
>>
>>   A bit late to the party, with a couple of thoughts:
>> <snip>
>> Phase two expands this concept by making the core of bundler itself
>> aware of an environent variable (let's call it USE_BUNDLER for now),
>> which if set, causes it to not attempt to create or read a lock file,
>> and to just load the dependeincies based on whatever the system has
>> installed.  This is meant _only_ for pure rpm/deb style systems where
>> the gem can reasonably be expected to only have one version installed,
>> otherwise you are back to the situation bundler solves for us.
>>
>> </snip>
>>
>> any benefits of using an environment variable over a global/local 
>> config file? T
>> he latter would allow us to have rpm-based setup for system stuff, 
>> and keep bund
>> ler-based setup for development (would be my preferred configuration)...
>>
>
> My intent was actually that the env variable be set _in_ a config
> file, for the exact reasons you mention.  Something like a default
> system wide setting in /etc/bundler, which can be overridden either on
> the cli or in your .bashrc/.profile.  The reason I was leaning toward
> the env var is so that bundler doesn't need to go looking for a file
> anywhere, it can simply ask the environment for the setting, allowing
> the user to put it wherever makes sense.  If you have a strong
> arguement or more detailed alternative implementation, I would be more
> than happy to consider other approaches.  The main thing to me is it
> needs to be flexible enough to work on any distribution - rpm, deb,
> gentoo, whatever.
>
>> <snip>
>>
>>   If we can get upstream bundler to accept that not everyone who uses
>>   bundler is deploying things in the scenario they were attempting to
>>   solve, we may be able to coax it into working for everyone. </snip> 
>> Did
>>   anybody attempt talking to bundler devs? If not, I can volunteer...
>>   Cheers, -Dmitri
>>
>
> No, I have not approached upstream yet.  My intent was to not do so
> until we had a patch/pull request adding the feature.  This would
> aloow us to easily use it in fedora or rhel while we discussed with
> upstream, should there be enough need for it.  However, if you want to
> see if you can get them to warm to the idea and maybe even implement
> it for us, I would be happy to not have to do the code myself  :)
>
> -j
I noticed that there's another issue with bundler when used with Ruby 
1.9.3 in f17: 
http://lists.fedoraproject.org/pipermail/ruby-sig/2012-January/000802.html. 
Vit (I think it was you who was dealing with that) - did you hear 
anything back from bundler developers?

-d

> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig