I have two more Ruby newbie questions :)
I see a lot of Gems contain a "Gemfile.lock" file. From looking at the conventions in Fedora's packages, it's a good idea to not include the Gemfile.lock in RPMs. I'm trying to understand how Gemfile.lock relates to packaging.
General question: Is Gemfile.lock only intended to be a convenience for Ruby Gem developers? I thought Gemfile.lock was only for development, but it seems like its contents can also affect an application's runtime...?
Packaging question: In preparation for packaging up Gitorious, I've found that I need to delete some entries from Gemfile.lock in order to use alternate Gem versions. Is it always safe to override the version numbers in Gemfile.lock like this?
- Ken
Hi Ken,
Dne 19.4.2012 03:43, Ken Dreyer napsal(a):
I have two more Ruby newbie questions :)
I see a lot of Gems contain a "Gemfile.lock" file. From looking at the conventions in Fedora's packages, it's a good idea to not include the Gemfile.lock in RPMs. I'm trying to understand how Gemfile.lock relates to packaging.
General question: Is Gemfile.lock only intended to be a convenience for Ruby Gem developers? I thought Gemfile.lock was only for development, but it seems like its contents can also affect an application's runtime...?
Regarding the Gemfile.lock, I would suggest you to read [1].
Otherwise, there is not straight forward answer. Rails applications definitely uses Bundler, which by default reads the Gemfile.lock. For other applications, it depends. My suggestion is not to hardly depend on Bundler, i.e. do not use "require 'bundler/setup'" or similar in your app. You can always run "bundle exec yourapp" instead.
Packaging question: In preparation for packaging up Gitorious, I've found that I need to delete some entries from Gemfile.lock in order to use alternate Gem versions. Is it always safe to override the version numbers in Gemfile.lock like this?
I would suggest to remove Bundler dependency at all. Bundler will always use/create the Gemfile.lock. If you provide it by yourself and some component will get updated, the application fail. If you don't provide it, the application will try to create it but this will (at least should ;) fail, due to limited rights. The version resolution which Bundler provides is not needed, since the dependencies are determined by RPM (and occasionally they may differ from original dependencies in upstream). The only thing you will miss without Bundler is initialized and restricted environment, e.g. at the start of the application, Bundler reads the Gemfile.lock and place immediately all the gems into Ruby's load path and there is not possible to load other gem from your application in the future.
I hope that somebody from Aeolus will chime in with their experience with Bundler and how they use it.
Note that there was already some discussion about Bundler and packaging guidelines [2], but at the end, we did not found sound statement how to handle it correctly. So if you succeed with Gitorius, your solution might become standard ;)
Vit
[1] http://yehudakatz.com/2011/05/30/gem-versioning-and-bundler-doing-it-right/ [2] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-January/000759.html
On Thu, Apr 19, 2012 at 12:02 AM, Vít Ondruch vondruch@redhat.com wrote:
Note that there was already some discussion about Bundler and packaging guidelines [2], but at the end, we did not found sound statement how to handle it correctly.
Thanks very much for your email. I read over your links several times in an attempt to wrap my mind around the Bundler concepts. I think I'm slowly catching on :)
It sounds like most of the Bundler concepts are antithetical to RPM packaging? For example, the way an app will try to update its own Gemfile.lock seems messy to me. Also, there's a "bundle update" command... but it doesn't appear to be a way to roll this update operation back, so now Gitorious wants to update its Gemfile.lock to the newer gem versions I've inadvertently installed. Ouch.
- Ken
On 19/04/12 08:02 +0200, Vít Ondruch wrote:
Hi Ken,
Dne 19.4.2012 03:43, Ken Dreyer napsal(a):
I have two more Ruby newbie questions :)
I see a lot of Gems contain a "Gemfile.lock" file. From looking at the conventions in Fedora's packages, it's a good idea to not include the Gemfile.lock in RPMs. I'm trying to understand how Gemfile.lock relates to packaging.
General question: Is Gemfile.lock only intended to be a convenience for Ruby Gem developers? I thought Gemfile.lock was only for development, but it seems like its contents can also affect an application's runtime...?
Regarding the Gemfile.lock, I would suggest you to read [1].
Otherwise, there is not straight forward answer. Rails applications definitely uses Bundler, which by default reads the Gemfile.lock. For other applications, it depends. My suggestion is not to hardly depend on Bundler, i.e. do not use "require 'bundler/setup'" or similar in your app. You can always run "bundle exec yourapp" instead.
I can see why you would come to this conclusion/suggestion, but I have another thought on how to approach this, below. My concern here is if fedora (and other distros) start having to make such changes to libraries, there is going to both be a higher risk of error or something not being loaded properly, and higher cost of maintenance for the packager.
Packaging question: In preparation for packaging up Gitorious, I've found that I need to delete some entries from Gemfile.lock in order to use alternate Gem versions. Is it always safe to override the version numbers in Gemfile.lock like this?
I would suggest to remove Bundler dependency at all. Bundler will always use/create the Gemfile.lock. If you provide it by yourself and some component will get updated, the application fail. If you don't provide it, the application will try to create it but this will (at least should ;) fail, due to limited rights. The version resolution which Bundler provides is not needed, since the dependencies are determined by RPM (and occasionally they may differ from original dependencies in upstream). The only thing you will miss without Bundler is initialized and restricted environment, e.g. at the start of the application, Bundler reads the Gemfile.lock and place immediately all the gems into Ruby's load path and there is not possible to load other gem from your application in the future.
I hope that somebody from Aeolus will chime in with their experience with Bundler and how they use it.
Here I am :) Sorry for the delay, was off for a couple days. So, I have been trying different approaches to this over the last $time, and have had varying levels of sucess thus far. As others have said, the main problem is bundler and rpm/yum have very different views of the world. Unlike others on this list. however, I do not see the bundler view as incorrect. In fact, I think it really makes a lot of sense, as it guarantees the same _full dependency chain_ for a given app or library. If you install one 5 different machines at any different time, so long as you have the same Gemfile.lock, you will have the same versions of everything your app needs. The place where I think bundler falls down is lacking a built-in way to support our use case for rpm, deb, or or package managed systems that do not use purely rubygems.
So, first a quick summary of what we are doing _right this second_ on aeolus[1], then a map of where we plan to go with it shortly. Right now, in simple form, we just plain don't package our Gemfile/Gemfile.lock into the rpm. If rails/cucumber/rspec don't see a file, they just work as you would expect. Unfortuntely, part of what you have to expect for rails apps, is that it then doesn't know what libraries your app needs if there is no Gemfile to refer to. For now, we have gotten around this by adding a conditional block in our application.rb, which duplicates the libraries listed in the Gemfile. Obviously, this is far from ideal, but does work, and keep packaging for rpms simpler, at the cost of making it harder for upstream ruby developers, and easier to miss adding a dependency in all the correct spots.
This was always intended to be a temporary solution. It has seemed to me from the beginning that we should be using the same Gemfile whether we choose to have bundler involved or not, and that there must be some hook that we could use to make this happen. After much poking and thinking, I came up with something I think could potentially work not only for us, but all of ruby on fedora (and by extension, and system that relies on a package manager of some kind). Our next step doesn't quite get us to that point, but the second phase should do it. I ran this by someone from openshift (another red hat cloud project), and they had come to some similar conclusions, so I am hopeful of convincing more of the community, and eventually the bundler upstream, of buying into this idea.
Phase one is simply getting rid of our duplication of dependencies between the Gemfile and application.rb by extending bundler with a Bundler::Ext.system_require method. This simple levergaes some bundler internals to parse the Gemfile and read in the deps there without creating or touching the lock file. In order to work, this step requires we continue to not have a Gemfile in the rpm, so we will go with something more like Gemfile.in.
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. I realize this sounds incredibly simple, and it is for the most part. 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. The remaining detail I see is where to set this env variable system-wide, so it will not only work for an app like ours (which can easily set it in the initscript), but for _any_ app or lib on the system. I am thinking /etc/$something, but vit might have some more ideas there once we get that far (and assuming he were to get on board with this plan).
Long as this email was, I realize I may not have provided all the detail needed, so feel free to follow up with questions on this line of thinking, and maybe we can finally solve this thing once and for all.
-j
Note that there was already some discussion about Bundler and packaging guidelines [2], but at the end, we did not found sound statement how to handle it correctly. So if you succeed with Gitorius, your solution might become standard ;)
Vit
[1] http://yehudakatz.com/2011/05/30/gem-versioning-and-bundler-doing-it-right/ [2] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-January/000759.html _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On 04/24/2012 04:26 AM, Jason Guiditta wrote:
Long as this email was, I realize I may not have provided all the detail needed, so feel free to follow up with questions on this line of thinking, and maybe we can finally solve this thing once and for all.
This sounds like something I was planned to do, do you have any code examples for your suggestions?
thanks!
Ohad
On 24/04/12 21:20 +0300, Ohad Levy wrote:
On 04/24/2012 04:26 AM, Jason Guiditta wrote:
Long as this email was, I realize I may not have provided all the detail needed, so feel free to follow up with questions on this line of thinking, and maybe we can finally solve this thing once and for all.
This sounds like something I was planned to do, do you have any code examples for your suggestions?
thanks!
Ohad
I am working on phase 1 this sprint, hopefully phase 2 will be next sprint, so in a coupke weeks.
-j
----- Original Message -----
On 24/04/12 21:20 +0300, Ohad Levy wrote:
On 04/24/2012 04:26 AM, Jason Guiditta wrote:
Long as this email was, I realize I may not have provided all the detail needed, so feel free to follow up with questions on this line of thinking, and maybe we can finally solve this thing once and for all.
This sounds like something I was planned to do, do you have any code examples for your suggestions?
thanks!
Ohad
I am working on phase 1 this sprint, hopefully phase 2 will be next sprint, so in a coupke weeks.
-j _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Any updates?
m
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:
Long as this email was, I realize I may not have provided all the detail needed, so feel free to follow up with questions on this line of thinking, and maybe we can finally solve this thing once and for all.
This sounds like something I was planned to do, do you have any code examples for your suggestions?
thanks!
Ohad
I am working on phase 1 this sprint, hopefully phase 2 will be next sprint, so in a coupke weeks.
-j _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Any updates?
m _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
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? The latter would allow us to have rpm-based setup for system stuff, and keep bundler-based setup for development (would be my preferred configuration)...
<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
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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
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?
-d
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
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.
Vit
-d
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
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
Also, Is there an irc channel for Ruby SIG? -d
Vit
-d
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
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/b49e89da703...
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.
On 30/05/12 22:52 -0400, 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:
Any updates?
m
Phase one is complete, though I ut the initial batch of code directly in aeolus conductor[1]. I was going to put the Ext library up on our github incubator project[2], but realized one of my tests depends on a specific gem library being installed (tests a certain case where the require name doesn't match the name fo the gem). So, I need to at least disable that test for now before I can push it, which I will hopefully get to today or tomorrow. However, it is working well in initial use, and has allowed our project to run upstream (pure ruby) on rails 3.2, while keeping our fedora/rhel releases running on 3.0.10 (meaning we will be ready to use the newer rails the second it is supported on those platforms).
I'll send an update when I have pushed BundlerExt to github, thanks for the reminder.
[1] https://github.com/aeolusproject/conductor [2] https://github.com/aeolus-incubator
-j
ruby-sig@lists.fedoraproject.org