http://bugzilla.opensuse.org/show_bug.cgi?id=1069441 http://bugzilla.opensuse.org/show_bug.cgi?id=1069441#c4 Zaoliang Luo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zluo@suse.com Flags|needinfo?(okurz@suse.com) | --- Comment #4 from Zaoliang Luo --- on TW I tried this manually for installation: -- couperin:~ # zypper -n in -C "rubygem(rails)" Loading repository data... Reading installed packages... Resolving package dependencies... The following 66 NEW packages are going to be installed: nodejs8 nodejs8-devel nodejs-common npm8 ruby2.5-rubygem-actioncable-5_1 ruby2.5-rubygem-actionmailer-5_1 ruby2.5-rubygem-actionpack-5_1 ruby2.5-rubygem-actionview-5_1 ruby2.5-rubygem-activejob-5_1 ruby2.5-rubygem-activemodel-5_1 ruby2.5-rubygem-activerecord-5_1 ruby2.5-rubygem-activesupport-5_1 ruby2.5-rubygem-arel ruby2.5-rubygem-bcrypt ruby2.5-rubygem-bindex ruby2.5-rubygem-builder ruby2.5-rubygem-bundler ruby2.5-rubygem-byebug ruby2.5-rubygem-coffee-rails ruby2.5-rubygem-coffee-script ruby2.5-rubygem-coffee-script-source ruby2.5-rubygem-concurrent-ruby ruby2.5-rubygem-crass ruby2.5-rubygem-erubi ruby2.5-rubygem-execjs ruby2.5-rubygem-ffi ruby2.5-rubygem-globalid ruby2.5-rubygem-i18n ruby2.5-rubygem-jbuilder ruby2.5-rubygem-jquery-rails ruby2.5-rubygem-listen-3_0 ruby2.5-rubygem-loofah ruby2.5-rubygem-mail ruby2.5-rubygem-method_source ruby2.5-rubygem-mini_mime ruby2.5-rubygem-mini_portile2 ruby2.5-rubygem-multi_json ruby2.5-rubygem-nio4r ruby2.5-rubygem-nokogiri ruby2.5-rubygem-puma ruby2.5-rubygem-rack ruby2.5-rubygem-rack-test-0_6 ruby2.5-rubygem-rails-5_1 ruby2.5-rubygem-rails-dom-testing ruby2.5-rubygem-rails-html-sanitizer ruby2.5-rubygem-railties-5_1 ruby2.5-rubygem-rb-fsevent ruby2.5-rubygem-rb-inotify ruby2.5-rubygem-sass ruby2.5-rubygem-sass-listen ruby2.5-rubygem-sass-rails ruby2.5-rubygem-spring ruby2.5-rubygem-spring-watcher-listen ruby2.5-rubygem-sprockets ruby2.5-rubygem-sprockets-rails ruby2.5-rubygem-sqlite3 ruby2.5-rubygem-thor ruby2.5-rubygem-thread_safe ruby2.5-rubygem-tilt ruby2.5-rubygem-turbolinks ruby2.5-rubygem-turbolinks-source ruby2.5-rubygem-tzinfo ruby2.5-rubygem-uglifier ruby2.5-rubygem-web-console ruby2.5-rubygem-websocket-driver-0_6 ruby2.5-rubygem-websocket-extensions The following 17 recommended packages were automatically selected: nodejs8 npm8 ruby2.5-rubygem-bcrypt ruby2.5-rubygem-byebug ruby2.5-rubygem-coffee-rails ruby2.5-rubygem-coffee-script-source ruby2.5-rubygem-jbuilder ruby2.5-rubygem-jquery-rails ruby2.5-rubygem-listen-3_0 ruby2.5-rubygem-puma ruby2.5-rubygem-sass-rails ruby2.5-rubygem-spring ruby2.5-rubygem-spring-watcher-listen ruby2.5-rubygem-sqlite3 ruby2.5-rubygem-turbolinks ruby2.5-rubygem-uglifier ruby2.5-rubygem-web-console The following package is recommended, but will not be installed due to conflicts or dependency issues: ruby2.5-rubygem-sdoc 66 new packages to install. -- ruby2.5-rubygem-sdoc i snot installed because of dependency issue. for run rails new --skip-system-test --skip-bundle mycoolapp I got following ERROR: .. Using coffee-rails 4.2.2 Fetching ffi 1.9.22 Installing ffi 1.9.22 with native extensions Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /usr/lib64/ruby/gems/2.5.0/gems/ffi-1.9.22/ext/ffi_c /usr/bin/ruby.ruby2.5 -r ./siteconf20180223-11658-17wna6r.rb extconf.rb mkmf.rb can't find header files for ruby at /usr/lib64/ruby/include/ruby.h extconf failed, exit code 1 Gem files will remain installed in /usr/lib64/ruby/gems/2.5.0/gems/ffi-1.9.22 for inspection. Results logged to /usr/lib64/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0/ffi-1.9.22/gem_make.out An error occurred while installing ffi (1.9.22), and Bundler cannot continue. Make sure that `gem install ffi -v '1.9.22'` succeeds before bundling. In Gemfile: spring-watcher-listen was resolved to 2.0.1, which depends on listen was resolved to 3.1.5, which depends on rb-inotify was resolved to 0.9.10, which depends on ffi run bundle exec spring binstub --all * bin/rake: spring inserted * bin/rails: spring inserted -- -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1069441 http://bugzilla.opensuse.org/show_bug.cgi?id=1069441#c6 --- Comment #6 from Dominique Leuenberger --- Dug a bit into that... there is a major difference between rails new -B mycoolapp (-B == --skip-bundle) and rails new mycoolapp -B The 2nd form is pretty much the one rails new --help declares as correct and has the extremely cool side effect of actually working (in as bundle install is being skipped, as asked for) The so-created app fails to start though in the end:

rails server Could not find gem 'capybara (~> 2.13)' in any of the gem sources listed in your Gemfile. Run `bundle install` to install missing gems.

rubygem-capybara does not exist in TW -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1069441 http://bugzilla.opensuse.org/show_bug.cgi?id=1069441#c9 Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High CC| |ammartinez@suse.com, | |dmacvicar@suse.com, | |fkobzik@suse.com, | |ikapelyukhin@suse.com, | |jordimassaguerpla@gmail.com Component|Ruby |Ruby Version|Current |Leap 15.0 Product|openSUSE Tumbleweed |openSUSE Distribution Target Milestone|--- |Leap 15.0 Summary|[Build 20171121] rails test |getting rails to work on |fails: Could not find gem |openSUSE is cumbersome |capybara | --- Comment #9 from Ludwig Nussel --- Moving over to Leap as this test is still red and getting rails to work sucks big time still. The work flow that works is # zypper -n in -C "rubygem(rails)" # zypper in gcc make ruby2.5-devel libxml2-devel glibc-devel libxslt-devel sqlite3-devel $ rails new mycoolapp --skip-bundle --skip-test $ cd mycoolapp $ bundle config build.nokogiri --use-system-libraries $ bundle install --path vendor/bundle $ rails server -b 0.0.0.0 That is far away from obvious and plug&play, at least not to me. So question to the rails folks. Is that work flow expected and well known? If not, how about documenting it in the wiki and/or release notes? Moreover, can we make that easier? For example, there already is a devel_ruby pattern. Would it make sense to just add the aforementioned devel package requirements to this pattern, so instead of installing the rails gem we document installing the pattern instead? Also, can the nokogiri config be made default? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1069441 http://bugzilla.opensuse.org/show_bug.cgi?id=1069441#c12 --- Comment #12 from Marcus Rückert --- (In reply to Ludwig Nussel from comment #9)

Moving over to Leap as this test is still red and getting rails to work sucks big time still.

The work flow that works is

# zypper -n in -C "rubygem(rails)" # zypper in gcc make ruby2.5-devel libxml2-devel glibc-devel libxslt-devel sqlite3-devel $ rails new mycoolapp --skip-bundle --skip-test $ cd mycoolapp $ bundle config build.nokogiri --use-system-libraries $ bundle install --path vendor/bundle $ rails server -b 0.0.0.0

That is far away from obvious and plug&play, at least not to me. So question to the rails folks. Is that work flow expected and well known? If not, how about documenting it in the wiki and/or release notes?

Moreover, can we make that easier? For example, there already is a devel_ruby pattern. Would it make sense to just add the aforementioned devel package requirements to this pattern, so instead of installing the rails gem we document installing the pattern instead?

Also, can the nokogiri config be made default?

1. You should *not* build all those gems via bundler. those gems are all there via system gems already. you pass --skip-bundle to tell it "do not run bundle install" ... but then manually do the step you just told it not to. 2. no we can not ... because you explicitely skip the system nokogiri with your bundle install. one could maybe patch the template files that rails uses but tbh ... we would need this "use system libraries" with so many libraries, maybe some which we dont even know about. that this is tedious. and some of the packaged gems we actually had to patch to allow building with system copies. 3. my steps: $ zypper in --recommends 'rubygem(rails)' 'rubygem(sqlite3)' 'rubygem(puma)' $ rails new mycoolapp --skip-bundle --skip-test $ cd mycoolapp $ export RAILS_ENV="production" $ rails server WARNING: Nokogiri was built against LibXML version 2.9.7, but has dynamically loaded 2.9.8 => Booting Puma => Rails 5.1.5 application starting in production => Run `rails server -h` for more startup options Puma starting in single mode... * Version 3.11.2 (ruby 2.5.0-p0), codename: Love Song * Min threads: 5, max threads: 5 * Environment: production * Listening on tcp://cubes:3000 Use Ctrl-C to stop ^C- Gracefully stopping, waiting for requests to finish === puma shutdown: 2018-04-24 10:22:48 +0000 === - Goodbye! Exiting this was on TW ... but basically should work the same on L150 we probably should add puma and sqlite3 to the recommends list. installing rails without the --recommends is a bit tedious but we do *not* want to add requires for all the other things because it is possible to create rails apps without using the recommended libraries. so moving the recommends to requires would be wrong. Adam: This has *nothing* to do with packaging rails apps. So a totally unneeded comment. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1069441 http://bugzilla.opensuse.org/show_bug.cgi?id=1069441#c15 --- Comment #15 from Marcus Rückert --- (In reply to Duncan Mac-Vicar from comment #13)

I can't speak for all ruby developers, but I have done enough Rails to have my own opinion.

I can't imagine the situation where I would use a distro packaged Rails.

I only need:

- ruby - rubygem-bundler

If you are fine with a) having all the devel packages on your host b) you are fine to having to redo all the fixes that we might have in our gem based packages (e.g. I had a seed-fu fix for a while) c) you are fine with not getting security and other bugfix backports. I totally agree for just installing ... bundle install is so much easier. sadly it totally sucks for maintenance. (In reply to Duncan Mac-Vicar from comment #13)

I agree with Ludwig, the steps on -devel packages are confusing, but OSX users have it worse, and the majority of Rails developers probably use Macs.

yes ... that's why we have so many intree copies of C libraries in Gems... the worst is the libv8 gem ... which is a complete libv8 runtime repackaged as gem. If you are lucky the gem upstream updates the copy of the C library ... and if you are even more lucky ... you can actually update to that to the version with the fixed intree copy. Now you could argue ... "I just build against the system copy" ... if the gem supports it.

For example, as Ludwig described, the pattern could install the devel packages of the most important gems, but additionally, it could install something in the environment that sets NOKOGIRI_USE_SYSTEM_LIBRARIES=1.

This env var is just the same his bundle config cmdline. If you don't want to use the rpmified gems. Feel free. But this bug is not about that. your use case is just working fine. There are users who want to use rpmified rails. And we need it working for rails apps that we ship. So can we focus on that for now? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1069441 http://bugzilla.opensuse.org/show_bug.cgi?id=1069441#c20 James Mason changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |james.mason@suse.com --- Comment #20 from James Mason --- Rails is just one example where we don't have an ideal solution for dev vs. production... ironically, for the case of Leap (for dev) to SLES (for production) it's fairly easy, and all the dependencies are there and matching. Things get tricky when you move development, say to Tumbleweed, and you have multiple projects with multiple targets... that's when things really go off the rails (pun intended ;-). After a decade of doing Rails on *SUSE* distros, the only solution that consistently works for me, is rvm for dev, and carefully crafted Gemfiles that match upstream packaging. Rvm is the saving grace that's allowed working on SLES12 projects with Ruby 2.1, projects running in Heroku on Ruby 2.4, new projects on Ruby 2.5, all without overpopulating my system with unnecessary libraries. If there's interest in making life easier for Ruby devs, what would help is packaged rvm builds for every Ruby version (as, 2.1 for example, no longer builds on Tumbleweed). (Of course this is all a digression from the original bug topic, sorry Dim*.) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1069441 http://bugzilla.opensuse.org/show_bug.cgi?id=1069441#c22 Marcus Rückert changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #22 from Marcus Rückert --- Thank you for the documentation but I think the bug as is wont be changed as it would bloat runtime installations. we already support multiple ruby versions and building gems for multiple versions. -- You are receiving this mail because: You are on the CC list for the bug.