Bundler holding back use of Rails engines?

rubyonrails-core
1

Hello :slight_smile:

I lost my last 2 weeks trying to unify model code of 2 existing rails apps in an engine. The apps share the database, so it made sense to unify the model code and some libs and common dependencies. Anyway, here comes: https://github.com/bundler/bundler-features/issues/65#issuecomment-120247185

Ι’m starting to get the feeling that bundler source code has gone a bit amok,

basically there’s a long line of closed or “low priority” issues that hold back the “split complex rails app into gems/engines” mantra that the Rails team has been pushing a couple years now.

For example:

  1. https://github.com/bundler/bundler-features/issues/65 - this issue prevents keeping gem versions in sync among apps using a common engine

  2. https://github.com/bundler/bundler/issues/3571 - :path is not supported with “package” - this means that any deployment mechanism depending on bundle package can’t work with local gems

  3. https://github.com/bundler/bundler/issues/2016 - workaround for last issue is to use git push on the engine and bundle update on the rails apps using it, which is irritating but OK - however when you go this route then every time you want to push a 1-liner code change bundler will try to update ALL of rails dependencies because an engine gem depends on rails. I tried removing rails from the engine gemspec, but it was no use, all of rails dependencies still got pulled

Unfortunately @indirect has been very defensive about all of these issues, according to him:

  1. using :git is a hack, you should publish private engines to rubygems.com

  2. using :path means “you handle packaging”

  3. not updating rails engine dependencies when you want to patch a piece of code from the engine is simply hard and not going to happen

Unfortunately, one gets a feeling that this defensiveness comes from the possible fact that bundler has become to unwieldy to follow Rails development goals and emerging deployment standards,

I get this feeling because in this issue @indirect said that 3000$ isn’t enough money for the trouble of developing a feature that should be a priority for the rails community anyway - the ability to handle large projects - so I’m guessing Rails has come to the end of the line where Bundler is concerned and that the rift will continue to grow.

Also, I get a bad feeling from the fact that this issue is the only one to which so far I have seen @indirect help someone circumvent a Bundler design problem, and this was only after he confirmed that @johnnyshields would pay 500$ for a hackish solution.

In fact he says it clearly:

https://github.com/bundler/bundler-features/issues/65#issuecomment-61932167

(To be super clear to anyone reading this ticket later: the above is a clever but dirty hack, it could break in future versions of Bundler, and the Bundler team only provides help with things like this if you provide monetary compensation.)

All of this leaves a very bad taste in my mouth because I’ve personally lost at least 2 weeks of my life handling these issues, and some of these discussions read as an Oracle support worker trying to explain to his clients that what they’re seeing is an intended feature and not a serious design issue that needs addressing, and any help will cost ya 500$

Not what I’ve come to expect from OS community…

Anyway, my 2 cents

2

The big problems with problems in my view:

  1. Gemspec and gemfile are separate. Gemfile allows using :github/:path, the gemspec does not. Gemfile is for “projects”, gemspec is for “gems”.
  • In NPM (node.js) there is a single file called “package.json” which handles both responsibilities in one scheme.
  1. Ruby gems pollute the global namespace. If I two gems that define the namespace Foobar, one will monkey patch the other.
  • Javascript (ES6) has a module system where each file must import and export. Thus I can do something like import Foobar from FoobarGem1 as Foobar and import Foobar from FoobarGem2 as Bazqux to avoid kludges.
  • Further point: when NPM gets dependencies, it gets a tree specific to each library. Hence you never get into the situation where two third-party gems clash in Bundler–each gem gets the correct version of it’s own dependencies. Both of these are major obstacles to scaling Ruby in production and are costing me real money in wasted effort. Frankly speaking I much prefer coding in Ruby than Javascript, and Rails is a great framework. But the JS community has it’s shit together, the Ruby community does not. Not to disparage the work Bundler and Andre have done, but it has fundamental design flaws some of which stem from design flaws in Ruby (lack of module system).

(Copying to Ruby Core thread)

3

Not what I've come to expect from OS community....

I am feeling to much entitlement from your part. Do seriously think that any of the developers owe you anything? Do you seriously think that your time is more valuable than theirs? Developers which have already spend huge amounts of time writing the software you use for free! Open source software does not imply free support. One of the biggest selling point of OSS is that you can fix it yourself or you can pay someone to fix it for you. If this is not working out for you I invite you to use something else.

4

Hi. The entire Bundler really, really appreciates feedback. Thank you for letting us know about the problems that you have experienced, and we will take this feedback into account when making development decisions.

In the future, please give feedback in a way that respects the time and effort we spend to provide you with a tool that you can use for free. Since you decided not to do that in this case, this will be my only reply to this thread.

Finally, I wanted to clarify a few things. Some of the statements in your email are either rehashing very old questions and concerns that have been answered repeatedly, and some are just incorrect:

  1. using :git is a hack, you should publish private engines to rubygems.com

I have never suggested that you publish private engines to rubygems.org. It is a limitation of RubyGems that prevents gems from depending on git gems. That has nothing whatsoever to do with Bundler.

  1. using :path means “you handle packaging”

Using the path option means that the files are available on the filesystem. There’s no need to copy the files to somewhere else if they’re already on the filesystem.

  1. not updating rails engine dependencies when you want to patch a piece of code from the engine is simply hard and not going to happen

If you want to update an engine without updating all of its dependencies, you can either update the version in your Gemfile or use bundle update --source GEMNAME.

Again, we appreciate feedback about Bundler, and we’re happy to receive it. However, the Bundler code of conduct applies to the Bundler issue trackers. Please file tickets without personal attacks if you want to start a conversation. Taking your reply full of personal attacks and posting it to the Rails core mailing list is not helpful if your goal is to find a solution to your problem.

5

Let me first concur with André and Jorge. Your entitlement is unwarranted (literally, as in there is no warrant for this level of entitlement per the MIT license of both Bundler and Rails), and decreases the odds that anyone is going to donate time to address any of your issues as a matter of good faith.

Second, “the “split complex rails app into gems/engines” mantra that the Rails team has been pushing a couple years now”. Not sure where you got this from. I’m not pushing this. I think it’s generally a bad idea. Less bad if the sharing is just a few models, more bad if its controllers, and extra bad if views are included as well. So you’re right: Dealing with bigger apps by splitting them into a bunch of engines is not well supported because it’s not a use case or pattern that has much backing from Rails core.

But the lovely thing is that this is open source! You get to see all the code, and if things aren’t being fixed by the community at large, you can fix it yourself or pay someone else to do it for you. So please do that and come back with some PRs that the teams can consider.