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
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.