Use Bundler.setup Instead of Bundler.require
anti-pattern.com
Use Bundler.setup Instead of Bundler.require
1–10 of 15 posts
Re: Use Bundler.setup Instead of Bundler.require
#2If you subscribe to the philosophy that every line of code is a liability, which I do, this really hits home.
Re: Use Bundler.setup Instead of Bundler.require
#3If you subscribe to the philosophy that every line of code is a liability, which I do, this really hits home.
The best code is no code.
Re: Use Bundler.setup Instead of Bundler.require
#4Wow, I'm always excited to see Rubyists promoting things being explicit in code. That's my primary gripe with Ruby projects, too much magic fairy dust and freebies that generates complexity. I'll keep this tip in mind when I play around w/ Rail/Grape next time.
Re: Use Bundler.setup Instead of Bundler.require
#5Wow, I'm always excited to see Rubyists promoting things being explicit in code. That's my primary gripe with Ruby projects, too much magic fairy dust and freebies that generates complexity. I'll keep this tip in mind when I play around w/ Rail/Grape next time.
I think a lot of this unfortunately comes from Rails. Rails hides a lot of complexity which creates "magic". And since most Rubyists come to Ruby from Rails, a lot of Rubyists have the bad habit of hiding complexity wherever possible. I was guilty of that myself. But I've noticed it slowly starting to change.
Re: Use Bundler.setup Instead of Bundler.require
#6In a language with a more rigid module system I'd agree with this, but Ruby's is really problematic for this sort of thing. Your requires will eventually cease to be documentation as they go stale, and you'll almost certainly accidentally use a dependency you don't require. All of this results in Weird Dependency Failures At A Distance.
If there's one thing I wish Ruby would adopt from python it's the import namespace system. Then this kind of proposal would become more practical.
Re: Use Bundler.setup Instead of Bundler.require
#7I'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
> 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 to enforce it (certainly using Bundler.setup won't do so). You're always going to have everything that has been required elsewhere "pre-required" for you. I'll often start out explicitly requiring everything that a file needs when I start a project, and then end stopping when I look back at some file and notice that it lacks require statements for half the stuff it needs.
Re: Use Bundler.setup Instead of Bundler.require
#8In a language with a more rigid module system I'd agree with this, but Ruby's is really problematic for this sort of thing. Your requires will eventually cease to be documentation as they go stale, and you'll almost certainly accidentally use a dependency you don't require. All of this results in Weird Dependency Failures At A Distance. If there's one thing I wish Ruby would adopt from python it's the import namespac…
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.
Re: Use Bundler.setup Instead of Bundler.require
#9I'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.
Re: Use Bundler.setup Instead of Bundler.require
#10In a language with a more rigid module system I'd agree with this, but Ruby's is really problematic for this sort of thing. Your requires will eventually cease to be documentation as they go stale, and you'll almost certainly accidentally use a dependency you don't require. All of this results in Weird Dependency Failures At A Distance. If there's one thing I wish Ruby would adopt from python it's the import namespac…
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 stale dependencies.
Then something requiring that file will have that dependency in place and possibly use it without requiring it because of that. This file now has incorrect dependencies.
Expand the above across a more complex project and it becomes virtually impossible to verify the correctness of your requires, so you probably just stop trying and require things as needed, which makes it worse.
When you finally discover it your changes (in your version control) become less isolated as random requires start popping in and out.
This is not a new or unique problem to Ruby, obviously. C/C++ headers have a very similar problem.