-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Add :dest and :path sub-options to :git #396
Comments
Here is the specific use case for this: rspec-rails' development environment depends on rails being included in the bundle. It also requires that rails be stored in a local repo so that we can easily get from one version of rails to another by simply checking out the appropriate tag. This is stored ./vendor/rails. The Gemfile in the root of the rspec-rails project includes: gem "rails", :path => "./vendor/rails" This leads to a catch 22, because when you first clone the rspec-rails repo and run "bundle install" the rails repo hasn't been cloned at ./vendor/rails yet. This can't be managed with a rake task, because the Rakefile operates in the same bundle, which won't load because the ./vendor/rails repo is not present. So the only way to get into a working state is to manually clone the rails repo, after which all is right with the world. If bundler added support for :path and :git in the same declaration, |
So :path by definition implies that you are saying "I'm going to manage this myself. Bundler, don't mess with it." The reason I am wary of implementing this is that I had previously thought about path + git support, but it did the exact opposite: if the path is not present, it would use the git repo as a standard git gem instead. That's because a lot of people use :path locally but need to use :git when they deploy. While I'm not sure about adding this to bundler without some more discussion, have you thought about creating a simple bootstrap.sh or similar file that checks out rails for you? |
This isn't about me, it's about my users. I want rspec-rails development to be as easy as possible for contributors, and having to clone, bootstrap, and bundle install is 50% more steps than necessary :) |
Well, the bootstrap would obviously clone and then bundle install... so it's still a single step, just a different one than bundle install. :) |
Sure, but So perhaps another solution would be to have a way to manage messages emitted by bundler. gem "rails", :path => "./vendor/rails", :message => "./vendor/rails does not exist. Try running 'git clone git://github.com/rails/rails.git ./vendor/rails' WDYT? |
I feel like managing the version of vendored rails in this fashion is outside the scope of what bundler is intended to do, but I'll continue to think about this. I may become persuaded. |
I'm also curious to hear your thoughts on this issue as it interacts with #231, which is a request to use :path in development and :git in production. |
I'm uncomfortable with expecting different behavior in different environments. I think it would lead to confusion, especially when the local and remote HEAD commits are different. |
So how would you handle the case of local development and production deployment? Simply say "that's not allowed"? Suggest the hacky ENV workaround explained in #231? |
Why not just do that by groups: group :development do gem "mongoid", :path => "#{ENV['DEV_BUNDLE']}/mongoid" end group :production do gem "mongoid", :git => "git://github.com/durran/mongoid.git" end |
Because unfortunately that doesn't really make sense -- Using groups in that manner declares two gems, both named mongoid, one of which is at a path that may or may not exist, and the other is in git. How can bundler arbitrate between two contradictory gem declarations in a single manifest? :| |
Couple of thoughts come to mind.
gem "mongoid", :git => "git://github.com/durran/mongoid.git", :only => :production gem "mongoid", :path => "local/path/to/mongoid", :except => :production
gem "mongoid", :env => { :development => { :path => "local/path/to/mongoid" }, :production => { :git => "git://github.com/durran/mongoid.git" } } Both have benefits and drawbacks. Just floating ideas. |
I need something like this for Devise. Devise depends on Rails and I have both checked out as a git repository in the same folder. Since I don't want bundler to checkout Rails once again, I do this in my Gemfile: git "rails", :path => "../rails" But that obviously won't work if you don't have Rails there. So it would be nice to be able to say: use this path, if not, check it out. For me, I don't care if rails will be checked out at "../rails" or BUNDLER_DIR, both would work great in my case. |
I talked this over with yehuda, and I think this is a really nice option to add to Bundler, but we should name it something else because it totally conflicts with the idea behind :path. How about this:
We could go with :dest, or :destination, or :clone_to, but I think I like :dest best. What do you guys think? |
I think David and I have different use cases. David wants to vendor it inside, I simply want to use that path/dest and, if not available, checkout the git repo (probably at the usual ~/.bundle location). In any case, :dest as option sounds great! |
I think I am proposing that :path + :git be used for José's case (try this path, if it's not there, then clone this git repo as usual), and :dest + :git be used for David's case (try this path, if it's not there, then clone this git repo into that path). I will of course add documentation for these options to the git page of gembundler.com, since those uses aren't exactly obvious. Hopefully, though, the combination of :path and :git I am proposing is such that nothing will break. |
Awesome! Victory! Success! |
Both use cases say "try this path, then do something else". Where they differ is in the "do something else" part, not in the "path" part, and the difference is the destination. José's case is to store it in the bundle, mine is to store it in the :path. So how about this:
The default could be :bundle, so you José can just say:
WDYT? |
Either that, or something like this:
Very explicit. |
I guess they don't seem like the same thing to me because in the one case, :path is the main option, and :git is a fallback in case :path doesn't work. In the other case, :git is the main option, and :dest is a sub-option to :git, like :ref is. I'm not sure yet how to make that clear in the API, though. |
"I think I am proposing that :path + :git be used for José's case (try this path, if it's not there, then clone this git repo as usual), and :dest + :git be used for David's case (try this path, if it's not there, then clone this git repo into that path)." +1 for this approach. |
Is it not better to make any src-dest and fallback behavior explicit, unlimited and consistent between
Current behavior to remain (call these git-strings and gem-strings use cases):
Inroduce a 'Git-hash'
Also allow a 'Gem-hash':
In both hashes
Note that when the
Or when the string is any valid Git URI:
Specifically
Finally, the
I believe this solves dchelimsky's:
and
and also josevalim's:
and
|
Your "gem hash" doesn't make any sense. Why would you ever combine |
Fair enough, drop it. From my reading of the above comments fallback behavior was really valued, and it'd be nice to have that behave consistently between |
As my comment above makes clear, the function of On reflection I think the correct way to address the 'issues' with indirect: please think then count to 100 before dismissing and closing Issues #577, your perfromance in both Issues #319 and #320 didn't leave an impression of taking thoughtful care in closing tickets - hopefully it was just a bad week. |
+1 for the "Try :path first, use :git otherwise" or "Different sources in different groups" solutions.. This issue is really annoying when developing a main application and several gems at the same time :/ |
What's the status on this? From the comments, it looks like it has been fallow for almost a year. Is this planned? |
The status is "on the list of things that would be nice to implement when we have time". The core team has limited time and is spending most of it on more universally applicable issues like speeding up |
Just like to interject this idea. There should be a :host option for gems. This way each developer can specify their own path to the gem and also specify different gems for different machines whether production or development. |
Wasn't this feature supposed to be scheduled for 1.1 as per this blog post (scroll to bottom)? http://www.cowboycoded.com/2010/08/10/using-2-sources-for-a-gem-in-different-environments-with-bundler/ +1 from me, this feature is something that would help gem development immensely! Hope it gets implemented soon. As of right now, I'm doing it like this:
|
On Tue, Oct 4, 2011 at 7:15 PM, James
Does anybody know what the status is? I hate doing "bundler situps" |
This will be implemented once there's a pull request with tests or someone on the core team has time to do it. We decided to pull the trigger so that everyone could have immensely faster installs, and we'll keep working on other features (like this one) as we have time. On Oct 4, 2011, at 11:32 AM, Tim Uckunreply@reply.github.com wrote:
|
Whoa, didn't realize this ticket was still open. :) As of version 1.2, Bundler allows you to use a git repo that is checked out onto your machine without editing your Gemfile via a particular |
I'd like the ability to specify both the
:path
and:git
keys in the samegem
declaration:During
bundle install
, if the repo exists at :path, use it. If not, clone from the :git location and store it at :path. Duringbundle update
, do agit pull
from the repo located at :path.The text was updated successfully, but these errors were encountered: