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 rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Reply via email to