4 ms·
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 y
by mnarayan01 14y ago
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 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.
- anti-pattern 14y agoYes, but, if you test your classes in isolation, then you'll be forced to manually require each dependency at the top of the file.
- mnarayan01 14y agoStormbrew said pretty much everything I would (https://news.ycombinator.com/item?id=5370718 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 ;)