Gemfile.lock questions

[Emanuel Rietveld]

On 06/04/2012 03:39 PM, Dmitri Dolguikh wrote:
> On 12-06-04 3:22 PM, Vít Ondruch wrote:
>> 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.
> Yup, I understand this - just trying to get my bearings.
>
> Is there current state, list of goals/notable issues/etc somewhere? I
> couldn't find anything on Ruby SIG wiki. If not, would it be useful to
> have? Personally, I think so, it would serve as a starting point for
> folks interested in helping out. This would clarify things (if nothing
> else) for Fedora ruby users in general too. To illustrate my point:
> https://github.com/carlhuda/bundler/issues/1959
>

WRT to the ticket you linked, you may be interested in this message I 
posted to the ruby-bundler mailing list

http://groups.google.com/group/ruby-bundler/browse_thread/thread/b49e89da7038af32

The thread contains a patch to make bundler compatible with Fedora's 
rubygem rpm packages. The developers have not yet shown any intention to 
merge that patch.