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.
I don't think I have a strong argument for the config file vs. 
environment variable. Just a general preference for the former. Having 
said that, if we don't foresee an explosion of config options for 
bundler (I certainly don't) in the near future, it makes sense to go 
with w/e is simpler at the moment (env variable being slightly simpler).
>
>> <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  :)
Ultimately, it's going to be upstream's developers decision as to which 
approach to this problem they favour. Wanted to make sure that they are 
not opposed to our approach. I'd be happy to chat with them.

-d

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