Skip to content

Instantly share code, notes, and snippets.

@wycats
Created February 25, 2012 09:14
Show Gist options
  • Save wycats/1907466 to your computer and use it in GitHub Desktop.
Save wycats/1907466 to your computer and use it in GitHub Desktop.
~/Code/ember.js ‹ruby-1.9.3› ‹master*› $ bundle && echo "fuck you giles"
Using rake (0.9.2.2)
Using confparser (0.0.2.1)
Using multi_json (1.0.4)
Using execjs (1.2.13)
Using libxml-ruby (2.2.2)
Using faster_xml_simple (0.5.0)
Using httpclient (2.2.4)
Using json (1.6.5)
Using nokogiri (1.5.0)
Using net-github-upload (0.0.8)
Using github-upload (0.0.2)
Using rack (1.4.1)
Using thor (0.14.6)
Using rake-pipeline (0.6.0) from https://github.com/livingsocial/rake-pipeline.git (at master)
Using rake-pipeline-web-filters (0.6.0) from https://github.com/wycats/rake-pipeline-web-filters.git (at master)
Using sproutcore (0.0.1) from https://github.com/wycats/abbot-from-scratch.git (at master)
Using uglifier (1.0.4)
Using bundler (1.1.rc.7)
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
fuck you giles
@Roman2K
Copy link

Roman2K commented Feb 25, 2012

Well put. Bundler does return correct exit status codes. I don't know what he was talking about.

@tarcieri
Copy link

Ruby is hard, let's got shopping, or at least switch to Node.js

@gilesbowkett
Copy link

I think my argument about source :rubygems breaking convention over configuration remains entirely untouched by this gist, and bundle exec still basically amounts to re-configuring your command line every single time you invoke it. The only way bundle exec could break DRY worse than it already does is if you had to re-configure your command line more than once per line.

But my apologies on this exit status thing, because that was 100% my mistake. I've corrected it in the post.

@tarcieri
Copy link

binstubs, bro

@gilesbowkett
Copy link

Thank you. It never occurred to me that the solution to bundle exec breaking convention over configuration would turn out to be a configuration option. You have changed my life.

@tarcieri
Copy link

Or you could just use an rvm gemset and you don't have to type bundle exec in most cases. There's lots of ways you can avoid typing bundle exec if you don't want to... you're mad you have to pick one?

@wycats
Copy link
Author

wycats commented Feb 25, 2012

@gilesbowkett I didn't bother to respond to anything other than this because your post was sloppy and full of hyperbole. I'm not as charitable as @raganwald. Your sloppiness makes his analogy to Harlan Ellison laughable.

protip: if you're going to criticize something with the level of vitriol that you're throwing around here, at least get your facts straight. It might also be good to understand the rationale for the decisions you're complaining about.

@gilesbowkett
Copy link

@wycats Oh come on. Who's going to believe that? Yehuda Katz passing up the opportunity to correct somebody who's wrong? That's like Paula Deen turning down a bacon cheeseburger.

Here's a "wontfix" with regard to source :rubygems from 2 years ago:

rubygems/bundler#118

What this says to me is "we're not making convention over configuration a priority." That's the only criticism I've made on this particular web page right here, in the comments on this particular gist -- that Bundler doesn't make convention over configuration a priority. Is that really such hyperbole?

And where was the vitriol? I said Bundler was awesome, but not finished.

@tarcieri Thank you for providing me with further configuration options with which to resolve my concern that bundle exec breaks convention over configuration. I was aware of them before this discussion, but I appreciate your thoroughness. I don't know why you ask me what I'm mad about, but rest assured I'm feeling fine.

@tarcieri
Copy link

Much ado over a 1 line .rvmrc file. Should Rails generate that for you and shove RVM down your throat as "convention"? Would that really be a positive step forward? What if people don't want to run RVM on their servers? What if people want to use rbenv?

And for what, to have the one true way to get rid of "bundle exec" be gemsets? The other options are also valid. Pick the one you like the best.
Why are you making this sound so incredibly hard?

@brixen
Copy link

brixen commented Feb 25, 2012

In Rubinius, you can use -G to load the Gemfile. For example, rbx -G -S rake. FWIW, I think the "convention" of littering gem binary wrappers in your system directories is horribly broken. People should always be using -S foo. So, adding -G isn't huge, I think.

@denarced
Copy link

The reply made my day.
Now that's a retort, programmer style.
In case it's unclear, I'm referring to this command: bundle && echo "fuck you giles"

I've never touched Rails and only played a little with Ruby so I don't actually have an opinion on the rest of it.

@jimeh
Copy link

jimeh commented Feb 27, 2012

On the whole Bundler thing, I'd almost like to see something similar to what npm does. For example, Bundler could default to something like --path ./vendor/bundle --binstubs ./vendor/bundle/bin, just like npm installs packages to ./node_modules and binaries to ./node_modules/.bin.

That would mean bundle exec still works as it should, system gems are not touched, and those who don't like bundle exec just need to export PATH="./vendor/bundle/bin:$PATH". And for those who don't like the defaults, pass in --path and --binstubs yourself.

@gilesbowkett
Copy link

yeah, honestly, I don't give a damn what Bundler does, I'd rather just use npm. I'm only attempting to answer the questions out of a desire to be a good citizen, which seems overly generous in the context of that whole 'fuck you giles' part.

@tarcieri
Copy link

You do realize by blowing this whole thing out of proportion, your whole post was something of a "fuck you" to the entire Ruby community, right?

We're talking about a problem that's literally solved by a one line .rvmrc (amidst myriad other solutions), and you managed to turn it into an argument that Ruby has lost its way.

@gilesbowkett
Copy link

First, I think you mean an argument that Rails has lost its way. Second, a one-line .rvmrc does not solve the fact that source :rubygems is not a default. Third, if your solution to a project not respecting convention over configuration is a configuration option, you are not even paying attention to the question. Fourth, how on earth does your non-solution to my convention over configuration issue change the fact that Rails has not kept pace with HTML5 the way it did with Ajax? What does it have to do with ActiveRecord.new being an ActiveRecordClassFactory in denial? How does it affect my concerns about the fact that nobody but DHH uses Rails's testing "convention"? What on earth does this conversation possibly have to do with the tweets I posted from a long-time Rails vet pointing out that Rails apps require a lot more work to get up and running than they did back in the version 0.6 days?

We're not talking about a problem that's literally or even figuratively solved by one-line .rvmrc fix. The fact that you think it does means you didn't even get the point of the discussion. Likewise, the problem you imagine to be solved in this manner is not the core argument of my post.

And as for a giant "fuck you," you're dreaming. I'm not Zed Shaw. I didn't say I was going to put on my combat boots and kick Michael Koziarski's ass. I said Rails 3 was not a step forward the way Rails 2 was, and that developing in Node.js is more fun right now. Saying somebody made a mistake does not equate to a giant "fuck you." Get over it.

@Denommus
Copy link

@gilesbowkett I know this thread is inactive by two months, but I have some considerations to do.

I'm not a huge programmer. I had two years of experience with Rails 2.3.X (and did a lot of things out of the Rails way). But right now I'm starting a new project with Rails 3.2, and I loved it.

I don't know if I understand the whole bundle exec problem. I'm not even using RVM, I'm using rbenv, and I don't have a problem about it, I just installed the rbenv-bundler plugin.

About the source :rubygems, Rails generated a valid Gemfile from the start. So what?

I see the problems you are talking about. But I think they are really minor. The main progress on Rails 3, for me, was UJS. I think you remember how ugly and clumsy RJS was, and how difficult it was to think about a software using it. And most people didn't even got it! There were books teaching render :update inside the controller. It was awful! I always ended up using plain Javascript, because of it.

Also, it is a lot easier to use bundler then it was to use... I don't know, how did you include libraries? I had a hard time with ruby-rdf, at that time, and I doubt I'd have on Rails 3.2.

So, I think everybody that says "Rails 3.X was not an improvement!" is missing completely the point. The basic configuration that comes with rails new is sufficient for most basic projects, and if it's missing some module, just add it to the Gemfile.

@gilesbowkett
Copy link

I'll look into rbenv-bundler as a solution.

I said several times that Bundler is incredibly useful, and I definitely never said Rails 3 was not an improvement at all. I agree that many of the issues I raised are not of earth-shattering importance. In fact I don't believe I ever asserted otherwise. People got furious beyond words about a blog post in which I devoted at least one paragraph, maybe more, to discussing my own balls. I never thought I would have to say this, but I really think that nobody ever needs to take my balls more seriously than I do.

I actually enjoyed RJS but I avoided it for serious work of course. UJS is def better.

Your point about Rails generating the Gemfile, though, I can't agree with that. First, your solution only works when using Bundler with Rails. Second, to even be having an argument about whether or not source :rubygems should be the default when everybody knows for a fact it's the 90% use case is just an unmistakable and incontrovertible sign of severe dysfunction within the Rails community. It's just a ridiculous conversation to be having in the first place.

Q: Should the 90% use case be the default?
A: No.

And let's face it, 90% is generous. It's probably the 99% use case or more.

I even asked one of the Bundler guys on Hacker News if I could re-open an issue about making it the default, and never got a response.

@Spaceghost
Copy link

For what it's worth, if you interpret DRY as some holy quest to never type the same thing twice, you're going to have a bad time.

DRY is about not having the same behavior in multiple places. It's about segregating concerns of a system into separate parts, not saving keystrokes. Those are just helpful, and a byproduct of actually being DRY. Pushing that is like pushing code to test ratios, they're nifty and sometimes good, but they're a byproduct of good testing. Anything more is merely mental masturbation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment