I actually use Ruby a lot. One reason is that, when paired with a good dsl framework, it is often less code with greater clarity to write in Ruby than Python. A perfect example is Sinatra vs Flask. In Flask, routes are separate from the code and in decorators. In Sinatra, a route and it’s implementation is together as a closure, and ruby can do a lot of automatic magic for handling form arguments, json conversion, etc.
openSUSE has a darth of packaged gems in the main repo. Of course, you can always grab and build a gem directly, much like what pip does for python. But I like having pre-built gems. There is devel:languages:ruby:extensions in osc, but with thousands of packages it still surprisingly lacked a number of common ruby gems that I routinely use, such as sequel_pg to improve sequel performance, zmq, mqtt, and the fast c-coded json gem. It’s very easy to use gem2rpm to create packages, so I built a quick obs project for the gems I care about that are missing from opensuse default repos: https://build.opensuse.org/project/show/home:dyfet:ruby
Hi
Some are already built in devel:languages:ruby:extensions, I would suggest cleaning up eg add a change log, and submit and/or branch/update existing ones?
If you prefer gems from the official Ruby repositories,
I wrote this Wiki page long ago but more less still applies to current openSUSE…
I describe how to configure rbenv, and modified the install instructions to support all Users who might login (as well as both the logged in User and elevated). If you are happy coding only as the logged in User, you can follow the official install instructions for rbenv. Or, you can use RVM. Or, you can use chruby.
Similar to pip although I’m not sure what you mean by having to build packages you download using pip (for python). Those should also be pre-built as much as likely necessary but from Python repos instead of openSUSE repos.
Remember to take extra care not to interfer with any gems YaST2 depends on.
I once updated all gems as root using …
sudo gem update
… until I realized I broke YaST in several ways. I then had to reset some gems used by YaST to their respective distro-specific versions.
Examples with sqlite3 and fast_gettext gems:
gem uninstall fast_gettext --version 2.0.1
gem uninstall sqlite3 --version 1.4.1
zypper in -force ruby2.5-rubygem-fast_gettext-1.6.0-lp150.1.4.x86_64
zypper in -force ruby2.5-rubygem-sqlite3-1.3.13-lp150.1.7.x86_64
What makes this slightly frustrating:
many Ruby/Rails tutorials out there casually advise sudo gem update
because on every non-SuSE distro this usually works without problems
neither YaST nor zypper have any safeguards regarding these implicit dependencies
Although I’ve been wary of your scenario happening,
I’ve found that FWIW whenever you use a Ruby Manager to install gems from the Ruby repositories there hasn’t been a problem even when you enable the downloaded Ruby globally (the system path points to the new Ruby instead of the Ruby from the openSUSE repos. I’ve tested primarily with YaST which of course may not be sufficient). And, if there is a problem, at least using rbenv you are able to enable either only the application (defined by the directory tree) or in a command line console. Each of the Ruby Managers I listed should support this, and support running any number of Ruby side by side on your system.
I wouldn’t expect YaST or zypper from protecting against anything they aren’t aware of, and when you use gem you are using a different package management system… So you have to prepare or address potential problems with a tool like a Ruby Manager which will maintain alternative rubies completely separately from the openSUSE packages. BTW - If a person tried rbenv or rvm and decided to remove everything, it only requires deleting the entire single directory tree and the system should default back to openSUSE Ruby, it’s that simple. You could clean up paths used by the ruby manager, but it’s not necessary.
And yes, most distros don’t come with their own development language repos, in particular the debian based systems I’ve tinkered with in the past use the official repos only.
I agree, tools like rvm or rbenv may alleviate the problem. I tried out one of them a decade ago (when I still compiled my own Ruby interpreter), and I didn’t like it one bit. Maybe I have to give those tools another chance.
Considering how easy it would be for YaST or zypper modules written in Ruby to specify the exact gem versions in their require statements, I have to disagree here. Instead of notifying the user unequivocally that an incompatible version of a crucial gem was installed right at program start, they rather crash and burn later during execution with very long and technical traceback dumps (»undefinded method…« and the like). I was able to recover because I know how to read Ruby error messages — and I could help others fix their broken installation in the past, instead of re-installing all of openSUSE. I’d rather have YaST just make the cause and possible fixes of the problem clear right from the start.
Obviously, the YaST and zypper maintainers are under no obligation to foresee everything possible about the amount of breakage that a Rails developer with some sudo privileges may cause, just following some generic Rails tutorials; but: I would consider it a nicety, a professional curtesy, to improve error handling somewhat in this direction.
A notification with the gem versions in question would be sufficient, maybe with a recommendation to use one of the Ruby version managers in the future. That’s how I’d do it. I hesitate to do another Bugzilla ticket, though, considering the swift rebuke I got the last time.
(Pardon the pun… Swift is Apple’s newest addition to the set of modern programming languages.)
However, I do know one of the YaST developers personally. Maybe I’ll try it that way.
Yes, exact versions of a package are sometimes necessary,
Which is why RVM and RBENV exist… So you can install different Rubies side by side on your system and invoke any selectively for specific code.
I’m not saying that all apps will behave as nicely as YaST with any version of Ruby, and I’m sure that somewhere YaST developers maybe even on their own if not by requirement realize that the YaST module they build will likely have a very long lifetime and unless they want to create a maintenance burden would write their code and requirements as generically as possible.
So what you really are saying is I should pick up more opensuse packaging policies and consider participating in existing packaging efforts. That is not a bad answer at all, and is a valid point.
I hate coding to specific versions, whether ruby or python, so I always have preferred being rather generic in my own stuff. YaST actually is a reason I like openSUSE, but it was specifically because of the adoption or Ruby, and hence the idea it implies of having Ruby as a first class/well maintained language in the distro.
Hi
Yes, I think some just need updating, else if new submit to the development repository, if and when you feel comfortable with the status, then look at submitting to the distribution
This seemed to help. Other than making sure the specs really are correct with policies, and have a changes file (osc vc is helpful for that), it looks like osc can also be used to drive package requests. I like this, a lot. I have a few (non-ruby) things in my main home repo that I should get out there too…
How to add a new package to Factory
If you have never created a package before, you may want to visit this tutorial before you begin submitting packages to OBS.
First and foremost, your package needs to reside in a devel project, which will act as a feeder project to openSUSE:Factory for your package. The home: namespace is not permitted to act as a develprj. Look which devel projects with similar packages to yours are maintained, and when you have found a good project, try to contact its maintainers and tell them that you want to maintain a package there. The easiest way is to simply send your package to the devel project.
osc submitrequest -m 'I want to maintain python-cerealizer in Factory and would like to use devel:languages:python as the devel/feeder project.' home:yourname/python-cerealizer devel:languages:python
I wonder if worth considering automating a conversion tool like what you describe is worth investigating.
It would be a significant load to convert major repositories like the official ruby and python repos to remove most need for installing from them instead of the openSUSE repos, might even require a dedicated hardware. I’m not aware there is a project anywhere that packages them for RPM completely.
I had actually started with submitting updates for libosip2 & libeXosip2, because that is really core to what I do, I am not going to be able to pull those down from a gem or something if it is not in the repo, and the versions in openSUSE actually are years behind and carry vulnerabilities. But yes, the process of package maintenance is really super easy with openSUSE and osc, and the existing docs are pretty clear, too.
So far this has been a disappointment, I get automated emails every ?few weeks? reminding the people who are supposed to do reviews to do so, even for bug fixes, but nothing ever happens. It does not give me much confidence about submitting new packages.
