Gemfile.lock questions

[Vít Ondruch]

Dne 1.6.2012 22:42, Dmitri Dolguikh napsal(a):
> 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?

You should use Fedora's Bundler. Bundler developers are not involved 
yet, since the patches needs to be accepted into RubyGems first.


Vit



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