Bundle (1.1rc) bundle install --without still thinks it needs :git Gems.

[envygeeks]

jordon@envygeeks:$ rake bundle:install
rm -rf bundler
rm -rf .bundle
bundle install --path bundler --without dev
Fetching git://github.com/pry/pry.git
remote: Counting objects: 9986, done.
remote: Compressing objects: 100% (4342/4342), done.
remote: Total 9986 (delta 5702), reused 9773 (delta 5500)
Receiving objects: 100% (9986/9986), 2.80 MiB | 1.24 MiB/s, done.
Resolving deltas: 100% (5702/5702), done.
Fetching gem metadata from http://rubygems.org/.......
Installing json (1.6.1) with native extensions 
Using bundler (1.1.rc) 
Your bundle is complete! It was installed into ./bundler
Removing  (pry 4373b3d3c770)
jordon@envygeeks:$ rake pry
git://github.com/pry/pry.git (at master) is not checked out. Please run `bundle install`

Gemfile:

source "http://rubygems.org"
gem 'json'

group :dev do
  gem 'minitest'
  gem 'rspec'
  gem 'cucumber'
  gem 'pry-doc'
  gem 'pry-stack_explorer', '>=0.2.2pre1'
  gem 'pry', :git => 'git://github.com/pry/pry.git'
end

Simply doing require 'bundler/setup' in the Rakefile kills any of my manual Gem.available? 'pry' checks.
Behavior under current stable:

jordon@envygeeks:$ rake bundle:install
rm -rf bundler
rm -rf .bundle
bundle install --path bundler --without dev
Fetching git://github.com/pry/pry.git
remote: Counting objects: 9986, done.
remote: Compressing objects: 100% (4342/4342), done.
remote: Total 9986 (delta 5702), reused 9773 (delta 5500)
Receiving objects: 100% (9986/9986), 2.80 MiB | 1.03 MiB/s, done.
Resolving deltas: 100% (5702/5702), done.
Fetching source index for http://rubygems.org/
Installing json (1.6.1) with native extensions 
Using bundler (1.0.21) 
Your bundle is complete! It was installed into ./bundler
jordon@envygeek:$ rake pry
rake aborted!
Please run `rake bundle:dev`

Tasks: TOP => pry
(See full trace by running task with --trace)

[indirect]

Without does not (and cannot) remove the gem from the dependency graph. It simply lets bundler know not to install the gem and load it on this particular machine. It will still be downloaded, and may even still be installed if an included gem depends on it.

On Nov 25, 2011, at 1:05 AM, Jordon Bedwellreply@reply.github.com wrote:

jordon@envygeeks:$ bundle install --path bundler --without dev
Fetching git://github.com/pry/pry.git
remote: Counting objects: 9986, done.
remote: Compressing objects: 100% (4342/4342), done.
remote: Total 9986 (delta 5702), reused 9773 (delta 5500)
Receiving objects: 100% (9986/9986), 2.80 MiB | 1.24 MiB/s, done.
Resolving deltas: 100% (5702/5702), done.
Fetching gem metadata from http://rubygems.org/.......
Installing json (1.6.1) with native extensions
Using bundler (1.1.rc)
Your bundle is complete! It was installed into ./bundler
Removing (pry 4373b3d3c770)
jordon@envygeeks:~/Development/api.envygeeks.com$ rake pry
git://github.com/pry/pry.git (at master) is not checked out. Please run bundle install

Gemfile:

source "http://rubygems.org"
gem 'json'

group :dev do
gem 'minitest'
gem 'rspec'
gem 'cucumber'
gem 'pry-doc'
gem 'pry-stack_explorer', '>=0.2.2pre1'
gem 'pry', :git => 'git://github.com/pry/pry.git'
end

Simply doing require 'bundler/setup' in the Rakefile kills any of my manual Gem.available? 'pry' checks because it apparently thinks that pry is needed when I told it not to install :dev so it should have never been branded as a dependency.

---

Reply to this email directly or view it on GitHub:
#1552

[envygeeks]

On 1.1rc it still attempts to load it and find it even if you tell it not to load and install dev sets. Leading to:

jordon@envygeeks:$ rake pry
git://github.com/pry/pry.git (at master) is not checked out. Please run `bundle install`

Even though I did --without dev. That error happens no matter the situation under 1.1rc by just doing require 'bundler/setup' and it seems to only happen if the :git attribute is supplied with the gem method.

While one would think (or even assume) that this situation should happen (based on the example rake task) we designed our Rakefile to work around bundler error messages (because we built bundle and gem tasks that simplify the process `` and we don't explicitly require bundler for anything but our Heroku installs) and the user can also enable our Rakefile to automatically install :dev if they try to run a task doesn't have the required Gem. Without automatic installs this is what the user should see -- if they have bundler installed (a task hint):

jordon@envygeek:$ rake pry
rake aborted!
You have opted to do a minimal install. Please run `rake bundle:dev`

Tasks: TOP => pry
(See full trace by running task with --trace)

We also don't explicitly load any Gems (in the Rakefile) without first doing Gem.available? so we can customise the error output. With 1.1rc they don't see our error messages at all because require bundler/setup forces an error when it tries to load a Gem that was never installed in bundler in the first place.

[jasonroelofs]

group :deployment do
   gem "private_gem" :git => "git@github.com:private/repo.git"
end

+1 on this. I have a :git link to a private github repo in my Gemfile. I don't want to install these gems on our CI machine as it doesn't have access to this repo, and these gems aren't needed for testing, so I tried bundle install --without deployment. Nope, it still tries to clone the private repository and thus the install fails.

[indirect]

@jameskilton, you have to run bundle install --without deployment --deployment. Please read the Bundler docs about deployment mode if you would like further explanation.

[jasonroelofs]

@indirect I'm not sure how that relates to the actual issue of Bundler still trying to pull in :git gems even though it's being explicitly told to ignore the group said gems are in. This is still a valid ticket, and I was giving another example on why this is a bug that should be fixed.

[indirect]

Regardless of the version of Bundler, running bundle install --without still needs :git gems to be checked out.

The --without option simply tells Bundler not to install those gems onto this system. As is stated in the Bundler docs, the intended use of the --without option is for gems that cannot be installed on the target system (for example, perhaps a development machine does not have the libraries required to compile a gem that runs in production).

The option does not (and cannot) actually remove the gem from the Gemfile. Bundler must always guarantee that the entire Gemfile is installable. To do that, Bundler must have the gemspec for all the gems, including that git gem, even if you aren't going to install it right at this moment. Bundler uses those gemspecs to verify that the set of gems is valid and meets the requirements stated by the Gemfile, Gemfile.lock, and those gemspecs.

In conclusion, this is not a bug. This is the way Bundler works. Even though you don't want to install all the gems right now, all the gemspecs have to be present right now so Bundler can ensure you will be able to install all of the gems at some later point. I apologize this ticket wasn't closed with a clear statement sooner, and I hope that that explanation makes sense. Please let me know if anything is still unclear.

[envygeeks]

Seriously? No seriously guy. Why would it need to check out something it's told not to use in the first place? That makes no damn sense. That would be like me telling Debian not to install recommends and then Debian saying 'naw dawg, we still gotta download them and put them in place, you just won't be able to use them.' Why would you need to guarantee something that it's told it won't need? The user isn't expecting it to be there if he is explicit in saying, don't be there. Why can you not download it when the user wants to actually install it? Is it going to magically disappear? And if t hat's the case and your excuse is yes, what is the case when it magically disappears after it's installed? Why would you need a gemspec for a gem it's told don't download. Bundler should not need to be aware of a gem it's told to hide. It should not need info about a gem it's told not to install. If bundler is going to do that it might as well download the troll gem. and be prepared for every gem currently in existence. Your software, your choice, bad reason and it's like you don't even read what's being said.

[indirect]

Seriously. I've explained why twice now, on top of the docs covering this exact issue in the section about --without.

Debian is completely irrelevant to this discussion, because it's a Linux distribution and not a package manager.

Debian's Apt package manager, however, serves to perfectly illustrate my point. Both Bundler and Apt require metadata for every package before you can install any of them. Apt downloads metadata separately from packages. Git gems, however, keep their metadata and the package itself together in the same repo. That means the repo has to be checked out (to get the metadata) so that installation of the other gems can proceed. If Apt supported packages directly from git repos, it would have to check out the git repos to get the package metadata too.

[envygeeks]

Way to make an irrelevant point while showing you know what I was on about. Doesn't matter anyways, would rather have sex with a lawn mower then argue with people who just don't understand that metadata is not needed to manage the state of a package and you don't need to give one shit about sub-dependencies of a package that's state should not even be known because the system was told to ignore it. I could see meta caching if you were managing 40GB worth of gems but at this point, it's useless especially since it doesn't speed up anything, since bundler is still slow as shit.

[myronmarston]

@envygeeks: You're being a rude jackass. Don't do that.

Bundler, like virtually all ruby gems, is free open source software. You are free to fork it and make it work how you think it should work, and you're free to file issues (as you've done here) when you think it should work differently...but don't forget that most people work on open source in their free time. Don't be a jerk.

[envygeeks]

@myronmarston In this case you wouldn't take the square wheel and make it a circle, you would just throw that shit out and make the wheel all over again. Just sayin' since you expect me to be a rude jackass while you, yourself, being a rude jackass for even mentioning it.

To the latter, I'll ignore it since it's not even worth replying to because obviously if it's free software you should not be critical you should just hold your head down and pray to the gods and hope that you get what it and you should certainly not be opinionated because it's free software and it only wants to be treated equally with paid software if you're nice to it.

[jasonroelofs]

I just want to say that we found a way around the issue we were having, and I'm sorry if my comments here came across in any way rude or confrontational. Bundler has made my life so much easier, thank you for the work you guys have put into this.

[myronmarston]

@envygeeks -- except for the "rude jackass" part (which I stand by, BTW), I think you misunderstood what I was saying, either mistakenly, or purposefully.

I'm not suggesting that you shouldn't be opinionated; anyone who has worked with me knows I'm very opinionated. I think open source project need passionate users who care enough to report their feedback and suggestions and file issues, as you have done.

The issue is how you treat people when you give feedback. People are always deserving of our respect, and even more so for open source projects, where it's free and people work on it in their free time.

FWIW, I think your issue has merit. This is surprising behavior. I understand the explanation @indirect gave above, but it doesn't change how surprising it is. It'd be great if there was a way to improve bundler here but I'm not sure how.

And in case you're wondering: I don't know @indirect at all. I've never met with him, emailed him or had a conversation w/ him on twitter. He may be just as much of a jerk as you are, for all I know. I just know that he took the time to provide an explanation for your issue, and you responded extremely rudely.

If you respond respectfully, I'll be happy to continue this conversation. Don't expect any more responses from me otherwise.

[indirect]

@jameskilton, I'm sorry Bundler wasn't able to work the way you wanted, but I'm glad you were able to come up with a solution. Thanks for reporting back, and your feedback is absolutely appreciated.

In the long-term, maybe we can come up with some kind of standard location for gemspecs in git gems that allows Bundler to avoid checking out the entire repo. It would require that the gemspec be ublic and accessible at install time, though. As for completely private repos, I'm not sure if there's anything that can be done that will allow Bundler to keep working correctly.

[envygeeks]

@indirect it wouldn't be such a problem if it downloaded the repo then moved the .gemspec and then deleted the repo entirely adding another piece to it's meta that 'partial' or something of the sort. For me it's more of a space issue then it is anything. While space is cheap moving that data between nodes is expensive sometimes (in terms of time.) It's also a matter of cleanliness exp: I don't expect something to be there it makes me investigate sometimes. Adjust the messages and mention that you are downloading to get the .gemspec but will be deleting the git repo after download is complete and getting the gemspec information.

@myronmarston I will keep my response to myself because the way you word things leaves me in a catch 22 that will lead to a response anyways considering it seems like you almost think you're better for sticking up for @indirect when you were just as much an ass as I was for calling somebody an ass (lowering yourself to my level while thinking you were standing above.) and then thinking you were good for it when you weren't. It intrigues me how people call somebody else and ass and then asks them to be respectful when they were undiplomatic too. Not my problem anyways because I'm not afraid to admit I'm an ass and I'm not one to call somebody an ass and then tell them to be respectful shortly after either. The short of the short is, no comment on the rest.