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(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
_______________________________________________
ruby-sig mailing list
ruby-sig(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig