Live data from Hacker News

Use Bundler.setup Instead of Bundler.require

anti-pattern.com

11–15 of 15 posts

Re: Use Bundler.setup Instead of Bundler.require

#11

Earlier quoted context omitted.

Interesting. Why would the requires go stale? And how would you use a dependency you don't require? It wouldn't be possible to use it unless you required it. This of course assumes you're testing your classes in isolation.

I think that isolation testing files is considerably harder than isolation testing classes . You can't force isolation of one by using isolation of the other. For requires going stale, I mean when a file originally depends on something but no longer does. The require is likely to linger, especially if the dependency is removed without knowing that it was the entirety or the last of the dependency. This file now has s…

Ah, well, nothing is foolproof. Yes, if you don't update your dependency list when dependencies are removed, they might get stale. But I keep up on that stuff and haven't ran into that problem yet. Even if I did, I'd rather have that problem than an app where all the dependencies are global.

Re: Use Bundler.setup Instead of Bundler.require

#12
Another thing to consider is thread safety. "require" is not thread safe, so if your app is multi-threaded, it's actually a good idea to load everything up front. Granted, you can still do this with manual requires, but Bundler.require does that job for you pretty nicely.

Re: Use Bundler.setup Instead of Bundler.require

#13

Another thing to consider is thread safety. "require" is not thread safe, so if your app is multi-threaded, it's actually a good idea to load everything up front. Granted, you can still do this with manual requires, but Bundler.require does that job for you pretty nicely.

Ah, that isn't something I considered. I don't write my apps multi-threaded, so it shouldn't be an issue, but definitely good to be aware of.

Re: Use Bundler.setup Instead of Bundler.require

#14

I'm not sure that there's really any way to give a firm recommendation either way here. You can, after all, simply add :require => false to any gems which you don't want to require with Bundler.require. > Manually requiring dependencies at the top of every file very explicitly tells you and anyone else exactly what dependencies that file has. While I don't disagree with this statement, I don't really know of any way…

Yes, but, if you test your classes in isolation, then you'll be forced to manually require each dependency at the top of the file.

Stormbrew said pretty much everything I would (https://news.ycombinator.com/item?id=5370718), but the one thing I would add is that most people are not going to keep their requires up-to-date for all but the most stable projects. Once your requires start to get stale/incomplete, they can easily become more of a liability than a benefit.

Again, I tend to agree with you more than I disagree. I think were I disagree is in making it a recommendation -- if someone is on point enough to effectively use Bundler.setup, I don't know that they need to have it recommended to them; they just need to know the difference between Bundler.setup and Bundler.require. On the other hand, if someone does need a recommendation and not a description, I'm not sure that either is the appropriate response.

I guess at the end of the day, I'm just not looking forward to the change-sets this might generate ;)

Re: Use Bundler.setup Instead of Bundler.require

#15

Earlier quoted context omitted.

I think that isolation testing files is considerably harder than isolation testing classes . You can't force isolation of one by using isolation of the other. For requires going stale, I mean when a file originally depends on something but no longer does. The require is likely to linger, especially if the dependency is removed without knowing that it was the entirety or the last of the dependency. This file now has s…

Ah, well, nothing is foolproof. Yes, if you don't update your dependency list when dependencies are removed, they might get stale. But I keep up on that stuff and haven't ran into that problem yet. Even if I did, I'd rather have that problem than an app where all the dependencies are global.

Sure. I guess what I'm trying to get at here is that, while I'm not fond of the Everything Is Magic approach rails often takes, I actually think this is one case where it was an entirely pragmatic effort to work around a poorly developed area of the ruby language when a program gets large (in terms of files, lines, or both). And Bundler.require is an evolution of that practice.
Post reply on HN