I have installed ruby 2.1.5 version and want to downgrade it to 1.9.3 to avoid "DL is deprecated, please use Fiddle in windows". I have tried rmv function, but it is not working and also tell me how to remove older versions.
So what's the issue ? Does migration complete ? If you mind just for the warning about DL being deprecated, downgrading to already unsupported Ruby version sounds ridiculous.
This may be just quite unharmful notice for developers to start using newer C-extension interface, while functionality is kept unaffected.
Related
I am going to maintain a rails application locally on Mac M1 based computer.
OS Version: Monterey 12.1
Ruby version 2.6.6
Rails version 4.2.11
I am getting this error and can't figure out what is actually causing this error to raise.
The error logged in console:
/Users/shimolkhan/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/dry-validation-0.13.3/lib/dry/validation/schema/class_interface.rb:8:in `<module:Validation>' [dry-configurable] default value as positional argument to settings is deprecated and will be removed in the next major version Provide a `default:` keyword argument instead
Please help me. Thanks in advance.
It looks like there may be a small incompatibility between the versions of dry-validation and dry-configurable that you are running.
This deprecation was introduced into dry-configurable 0.13.0 (the latest version) recently here:
Changelog Pull Request
Yet according to the fragment you pasted, you're running dry-validation 0.13.3, which is almost 3 years old.
I'd suggest updating your version of dry-validation and perhaps all dry gems.
ruby - 2.7.2
rails - 6.0
paperclip - 6.1.0
I am getting following warning in my console, while using paperclip gem with ruby 2.7.2
/Users/***/.rvm/gems/ruby-2.7.2/gems/paperclip-6.1.0/lib/paperclip/url_generator.rb:68: warning: URI.escape is obsolete
I know there are no maintainers for paperclip and it is deprecated but I cannot use active storage as I found paperclip is the easiest and best way for implementing attachments. How can I solve this warning ?
When you say "solve" the warning it's not quite clear what you might consider to be an acceptable solution. But you could:
a) Ignore the warning so long as you are sticking with these versions of Ruby and Rails, as it does not mean that anything is broken.
b) Write some code to suppress this specific warning, though I'd probably not do this as you'd increase the chance of forgetting about the issue, and then ending up with a more acute and time-sensitive problem down the road, if you upgraded part of your system to where URI.escape was no longer available.
c) Do what I've done in my Rails application, which is switch to a forked and maintained version of Paperclip, KT-Paperclip. If you wanted to update to the minimum version number that addresses these deprecation warnings, you'd choose 6.4.
Wellll the right answer is to do something better for your codebase as #UptDogTT suggests... but if you just need a get-it-done answer, this monkey patch adds URI.escape back using equivalent functionality. Add it as an initializer:
module URI
def self.escape url
URI::Parser.new.escape url
end
end
DISCLOSURE: I know very little about Ruby beyond some basic code syntax. Bear with my idiocy.
Ruby 1.8's OpenSSL library doesn't seem to support TLS 1.2. However, there are apps running that are dependent on 1.8, so I want to see if I can run a newer version of Ruby concurrently on the same system and get it set up with newer versions of the same gems.
Currently version 1.8 is at /usr/lib/ruby/1.8. Ideally, I'd like to keep the same structure and install a newer version (not sure what the most recent, stable version is - whether it's 2.3.x or 2.4.x).
That said, I am not a Ruby admin. I inherited a server from someone else who decided Ruby was the best way to do things, despite there being no other Ruby experience within the company, and then they left. I know some system admin stuff, but I don't know:
How backwards-compatible Ruby versions are (e.g. would an app built against 1.8 run without any major modifications on 2.4.1).
How gems work / get updated. Can 2.4.1 use gems from 1.8, or are gems tied to specific Ruby versions? Can there be a mix-and-match? Is there a migration path of some kind?
How to properly manage two different concurrent versions (how to tell an app to use one version over the other, or prevent existing apps from automatically trying to use the new version and breaking if they're not compatible).
Any best install practices (I usually compile from source, but am open to suggestions).
Is it even possible to just update Ruby's OpenSSL library without updating the whole Ruby app? It's currently on OpenSSL 0.9.8o, so it's pretty significantly behind the times.
The server is running Debian 6.0.6 (I'm more familiar with Red Hat and CentOS, though, so any hints on package management, etc... related to this issue would be welcomed).
Modern ruby has "matured" and become very stable. Upgrading from 2.0.0 --> (the latest stable) 2.4.1 is generally quite easy. However, ruby went through a period of fairly major (necessary!) changes from 1.8 --> 1.9 --> 2.0; this part of the upgrade may be problematic.
Gems are installed within the current ruby installation. So for example, you currently have the "ruby 1.8 version" of CanCan. If you update the ruby version of this application, you will need to re-install all gems (presumably via bundle install) for the ruby version. The migration path is basically: Get as comprehensive a test suite as possible; upgrade gems as much as possible within that ruby version; update the ruby version; fix tests and/or code if necessary; repeat.
Use a tool like rvm or rbenv to install multiple concurrent ruby versions on one machine.
See point 3. You probably don't need to compile anything from source.
Ruby 1.8 is old. Support for it was dropped back in 2013. Your application will undoubtedly have a huge list of outdated libraries now, with all sorts of security vulnerabilities -- that's what happens when you don't update it for 6+ years! From a security standpoint, I would not suggest trying to find some workaround for this one OpenSSL issue and ignore the larger problem here.
I am new to Ruby Development. Now i am working on ruby test-framework code which was working fine with Ruby-1.8.7
Now i want to upgrade ruby for this framework. I have found that test-unit-1.2.3 is included in Ruby-1.8.7 so i have installed it separately with Ruby-2.4.1.
Currently i am facing method missing issue ["register_autorunner"] with this combination. Because these method have not been used in ruby-1.8.7
Can anyone please tell me other changes needed to make this combination [Ruby-2.4.1 , test-unit-1.2.3] working.
Thanks in advance
You should update to TestUnit 3.x, which will have a higher chance of working with Ruby 2.x. Then you need to figure out the changes between Ruby 1.8.7 and Ruby 2.4.1, and how to fix your existing code, which is most likely broken, even after you have fixed/updated your unit test configuration.
Also, consider a switch to Minitest or Rspec, as they are a lot more popular today, so it will be easier to find examples and supporting tools for them. Minitest is also the default test framework used by Ruby on Rails currently.
References:
https://www.jetbrains.com/research/devecosystem-2017/ruby/
http://guides.rubyonrails.org/v5.1/testing.html
When updating jRuby, I'm always having a look at their release notes to figure out which ruby syntax I'm able to use. Quite recently, the change logs just say Ruby 2.x compatibility. Is there a way or place to find out against which exact ruby version it is compatible? I.e. ruby 2.2 differs from 2.3 quite a lot. Why are they just writing 2.x?
When you do a
jruby --version
two version identifiers are printed. The first one gives the jRuby version, and the second one gives the Ruby language version which this jRuby is based on.