Is there a web site that indicates which gems work on rubinius (or other implementations of ruby), like isitruby19.com indicates which gems work on ruby 1.9? (I'm curious about heckle working with rubinius in particular)
Yes, see here: http://isitrubinius.com/
There isn't as far as I know. If you want to know whether something works, you can download it and run its unit tests. Heckle won't work out of the box because it requires ParseTree, which merely raises a LoadError that says "ParseTree isn't needed with Rubinius."
Related
I am using a quite recent version of ruby (2.5.1) but some old gems. I am having some issues. I was wondering, is it correct that some gems work only with certain versions of ruby?
If a gem worked with ruby 2.3.0, is it true that it will definitely work with 2.5.1 (i.e. because 2.5.1 > 2.3.0)? Or is that not always the case?
I guess what I'm asking is are newer ruby versions always backwards compatible with older gems?
If a gem worked with ruby 2.3.0, is it true that it will definitely
work with 2.5.1
This is not correct. Programming languages are evolving while growing. This means language maintainers are doing lots of improvements or refactorings that they are new features or removing old components from the language. When the language community announces for new features or removing old feature such as Fixnum in ruby, the developers should follow the instructions and refactor their codebase accordingly. In other words, developers should have a good test coverage to detect any fail and fix it instantly.
In your scenario, as well as I understand you do not have a test coverage. The only but the simple thing should do is just upgrade your gems' versions to latest.
Gem is simply a plug-in library written in Ruby.
Of course, Ruby is developing, new features are appearing, old ones are disappearing.
It's best practice to specify Ruby version in .gemspec file. For example, like this one.
But if not, then you have to manually check the performance. So you can read gem source code or try to use your gem and check it.
For automation, of course, it is best to use tests.
Starting at Ruby 2.1.0 the version policy has been that a change in the MINOR version may introduce API breaking changes.
Should any gem happen to use an API that changes, an incompatibility will arise.
The MINOR version number has changed twice between 2.3.* and 2.5.* so even if a gem happens to have been written in accordance with the documented API, there's no guarantee that it will continue to work unless the gem's maintainer takes the effort to test the gem (and upgrade it if necessary). Automated test suites help a lot.
A standard way to document version compatiblity that is actually tested against is by providing required_ruby_version in .gemspec files.
Interestingly, if a particular gem is really badly written, I imagine it might break even between compatible versions of Ruby. That's not something I've encountered in the Ruby ecosystem but I've made a similar mistake writing Java code (and Java is famous for its backward compatibility) where my own code accidentally used a class that wasn't part of the API. There are many gems. Who knows what's out there? :)
I have a project with many Ruby files, loaded by external program with embedded Ruby interpreter (and some other libraries). I'm trying to use RubyMine and Rubocop to help with development, but the problem is that the said embedded interpreter is of version 1.9.2 and can't be upgraded in any way. Is it possible to still use the Rubocop or other linter inside RubyMine and at the same time to make sure the code is compatible with old interpreter?
Yes you can, Check this out and then let RuboCop know the oldest version of Ruby which your project supports with updating .rubocop.yml file:
AllCops:
TargetRubyVersion: 1.9
The short answer is that yes, it is possible to change the linter used in RubyMine, there are complete walk-throughs on JetBrains site explaining how. I don't know off the top of my head any linters that specifically work for pre-2.0 versions of Ruby, not to say they don't exist.
The longer answer is that it really won't make much difference if the interpreter is running through another program, and not using a real Ruby installation, and any linter is not going to reliably work for you. There will be plenty of code that a linter will still think is perfectly acceptable, but fail when running in an embedded VM.
# Linter thinks this perfectly fine, part of 1.9.2 standard library
require 'base64'
# Still thinks this perfectly fine. This all fails miserably though
Base64.encode64('My string')
The most obvious examples would be the entire standard library, gems, rake, and anything that is not part of the "core" library. Basic rule of thumb, if you have to require a script (excluding your project's local scripts), it is not going to work.
Another reason it could never be reliable is that you do not know if the embedded Ruby interpreter has been altered, or removed features from Ruby for their purposes, and a linter would have even less way of knowing that. Years ago I dabbled with the RPG Maker series, and discovered the hard way that their were certain built in features of Ruby that were removed (or at least hidden) from their custom build.
If you are familiar with Ruby, then you can obviously steer clear of the major and most common 2.0+ changes that Ruby implemented to the core library, but the only reliable way to know (even with a linter), is testing, which you will need to do anyway ( or at least you should). RubyMine has good support for automating this with Minitest and RSpec.
My question is about the ruby-doc.org documentation, but also relates to the ri documentation lookup inside ruby.
I've already read dozens of similar questions/answers about the ri not working and giving "nothing known" messages and I've tried to follow some of that old advice. It just seems that those old answers aren't applicable to me.
One was to install the rdoc --all --ri from the ruby root directory. I tried that and it failed (unable to convert to UTF8 or something like that).
Another suggested that the rubyinstaller for windows installer just doesn't contain that info anymore and I should use the online documentation, which, when I goto http://ruby-doc.org/downloads/ I discover that the version I am using (2.4.4) does not exist.
This is odd, because the rubyinstaller site specifically says that if I'm new to Ruby(which I am), I should install 2.4.4. You'd think that if any version had good documentation, it would be that one. Instead, it seems to be missing entirely.
This all started because I am trying to learn Ruby and am watching the Lynda.com course on Ruby by Kevin Skoglund, which was recorded many versions ago and in that course he refers to the ri command from the shell, which in my version doesn't work. see below:
ruby --version
ruby 2.4.4p296 (2018-03-28 revision 63013) [x64-mingw32]
ri --version
ri.cmd 5.0.0
ri String
Nothing known about String
Now, if it's not available within ruby using ri, and I have to use online documentation, AND it's missing for my version, which happens to be the version recommended for new users, … you see my frustration.
Here's what I really want...
1. I want to use ri and have it work.
2. If that's just not possible, I'd like to know where the documentation for my version is online, because it's not where it's supposed to be.
Any help is appreciated. If it involves installing anything, letting me know HOW to do that is also appreciated. As I mentioned, I'm new.
Since you are using the RubyInstaller, I will assume that you are on Windows.
I will open this by saying that I am not 100% on this, but I am pretty condfident in this answer.
The "Use 2.4, not 2.5" was due to errors with Ruby Gem when Ruby 2.5
was first released, as I happen to be on a Windows machine installing
Ruby at that exact time, and that was the reasoning at that point not
to use the newest 2.5 version.
The above mentioned reason has since been corrected.
Realistically, if you are beginner, as long as you using documentation that is close to your version (2.0+ - 2.4-ish), it will be fine. Now obviously, and I shouldn't have to provide this disclaimer, though I will so to avoid the inevitable down-votes if I don't, this is not 100% perfect solution and there will be very small differences. As a beginner, the likelihood of you encountering any of these differences are extremely low, low enough not to even worry about. There are missing and poorly documented sections of every language, and Ruby is no exception. Typically these are less used classes (though Ruby Fiddle is an exception that I hate how poorly documented it is), and will have no effect on your learning process as you learn the fundamentals and core of the language.
To my recollection, the "core" is rather well documented, and so long as you use documentation from 2.0+ (the closer to 2.4 the better), you should be completely fine, and it is exactly the same. The "standard library" may be slightly more hit or miss, and your mileage may vary a little more, yet still nothing too extreme.
So, to address the second part of your question, do not worry too hard about finding the EXACT version of documentation you are using. It may not even exist online, though the installer should have provided a CHM help file (there will be shortcut for it with the shortcuts for Ruby, IRB, etc.
As for "why" ri is not working, I am not 100% sure yet again. I am on ArchLinux, and RDoc doesn't even built. Honestly, RDoc is being left by the wayside for newer (and IMO better) document engine, namely YARD. A possible solution that I do, and prefer, is to install the YARD gem right after I install Ruby:
gem install yard
And then set YARD to generate my documentation with this in CMD:
yard config --gem-install-yri
If you decide to take this route, much more can be learned about it here.
The benefit with it is that it also supports RDoc and is backwards compatible.
i'm interested in updating code which is written in ruby v1.8.6 to 1.9.2. Are there any useful links to read about (probably with some warnings and recommendations)?
Just to be clear, so, i'm not expecting any problems right now, but i would like to avoid them.
P.S.
Links like this one are mostly not helpful.
A slideshow showing the differences: http://slideshow.rubyforge.org/ruby19.html#11
I migrated an app from ruby 1.8.7 to 1.9.3 a few days ago, and no problems happened.
Bu i advise you to test all of your code for little bugs.
Verify that all the gems you depend on are 1.9.2 compatible. isitruby19.com is a good resource to check this.
Other than that, the best strategy is to try migrating and do some testing. If your application has comprehensive unit test coverage, this shouldn't be too painful.
According to this post, requiring rubygems is an antipattern.
require 'rubygems'
The argument seems to boil down to this:
When I use your library, deploy your
app, or run your tests I may not want
to use rubygems. When you require
'rubygems' in your code, you remove my
ability to make that decision. I
cannot unrequire rubygems, but you can
not require it in the first place.
But couldn't the same argument be made about any Ruby library that you 'require' when you create and share a library of code with other people?
If you look at the comments, you will see the author say this
The point I was not trying to make is
that rubygems is bad or that people
shouldn’t use it. I use rubygems and
think it’s a critical piece of Ruby’s
success – I just don’t have the line
“require 'rubygems'” anywhere in my
library’s source code because it’s not
necessary or convenient and makes it
hard / impossible for other
environments (like bundler, rip, GAE,
debian, hand rolled, etc) to use the
library without rubygems, which is
often important.
I actually didn't really agree with him before I read it, now I do
The main problem with requiring rubygems is that it will cause an error on systems that do not have rubygems installed even if they do have the library that you actually want to require.
Some people work around that by rescuing LoadError when requiring rubygems, but that's kind of ugly.
Rubygems isn't essential to the application, it's just a convenient way of supplying a library. By contrast, the other libraries used are essential to the application.