Gemfile.lock questions

[Jason Guiditta]

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