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. 2) 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) On Friday, July 10, 2015 at 3:29:57 PM UTC+9, Borna Novak wrote: > > Hello :) > > 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 > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
