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
Related
When authoring a gem, what would be reccomended practice for version restrictions of dependencies. For example I know that know that my gem works wih rubyzip version 2.x, but I also know that it works for 1.9 as well. Should I state
spec.add_runtime_dependency 'rubyzip', '>1.8'
or if the rubyzip version 1.9 is long time outdated, it is more common to "push" change for 2.x line? Also if I use the mentioned line, that I risk incompability with future versions, but on the other hand, leave the coice to the user.
Note: the questions is generall and dependency on rubyzip is just an example.
If you know that your gem works with rubyzip 1.9, then there's really no need to force people to use >=2.0 with it.
Sure, updating dependencies would be a good idea for your library-user to do, but it's not your job to be the "update-your-software-police"!
Specifying that the version must be < 3 is generally advisable (although not consistently done by developers), as there's a reasonable risk that a major dependency version bump will be incompatible with this version of your code.
So, as a compromise, you could do:
spec.add_runtime_dependency 'rubyzip', '>=1.9', '<3'
See the documentation for valid syntax examples.
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? :)
When I run my Rails app in WEBrick on Ubuntu, after upgrading to ruby-1.9.3-p327, I receive the following error:
[rake --tasks] /home/dsilver/.rvm/gems/ruby-1.9.3-p327/gems/em-dir-watcher-0.9.4/lib/em-dir-watcher.rb:7: Use RbConfig instead of obsolete and deprecated Config.
Any idea what's going on?
I've seen some posts connecting this to ImageMagick on Windows. I am on Ubuntu, but the app does use ImageMagick, and the ImageMagick functionality appears to have broken since the ruby upgrade from 1.9.2 to 1.9.3. I suspect a connection.
Thanks!
The Config module has been renamed to RbConfig. It’s still possible to use the old name, for backwards compatibility, but Ruby issues a warning if you do.
The em-dir-watcher gem uses the old name, and so you see the warning when it’s loaded. Someone has already sent a pull request fixing this, however the last update to em-dir-watcher was over two years ago so it might not get merged.
This is a warning that is generated, not an error, so your code should actually still work okay. If you really want to get rid of the warning you could add something like this before you require 'em-dir-watcher':
Object.send :remove_const, :Config
Config = RbConfig
This defines Config to be the same as RbConfig, which is what Ruby does anyway, but prevents the warning.
You can do (not recommended):
Go to the file ../lib/ruby/1.9/rbconfig/obsolete.rb
Edit the file, the change is commenting the line #warn ...
With that change, eliminated the advice "warn"
Using jruby 1.5.1
In a pretty simple cronjob that uses gems:
dbi
dbd-jdbc
jdbc-mysql
It also uses a pure Java JDBC driver in a jar, jtds-1.2.5.jar
Every time I run it, I get this in STDERR (which is annoying my cronjob monitoring utilty which thinks anything on stderr may be a problem)
/usr/local/rvm/gems/jruby-1.6.5.1/gems/deprecated-2.0.1/lib/deprecated.rb:199 warning: already initialized constant Deprecate
?? Any ideas? What's going on, what can I do about it? Not sure which of these gems depends on 'deprecated' library or what version, any easy way to find out?
Ah, okay, figured it out:
[rochkind#catalyst pull_reserves]$ gem dependency dbi
Gem dbi-0.4.5
deprecated (= 2.0.1)
But 0.4.5 is the most recent version of 'dbi', and it is locked to 2.0.1 of 'deprecated'. There is a more recent 3.0.0 version of deprecated.
Okay... not sure what my question is now, except if anyone can figure out more about what's going on, and what my actual options are. I guess report as an issue to 'dbi' gem, hoping it's got some maintainers who care, I dunno.
more update: Okay, and there's already an issue filed for this, from August. https://github.com/erikh/ruby-dbi/pull/8 Looks like the gem is not very maintained. sigh. sometimes ruby community really frustrates me.
I think this is what you need:
Suppress Warnings From Ruby
A comment there mentions the Rails method to silence warnings, but I don't think you're using Rails.
EDIT: I found slightly cleaner code here:
https://mislav.net/2011/06/ruby-verbose-mode/
EDIT: Note: A commenter below seems to disagree with the blog entry mentioned above. I'm not expressing agreement or disagreement with the blog entry and I'm not opinionating on the goodness or badness of Ruby's verbose mode, merely crediting the author for the slightly cleaner code I found there.
I think this is what you'd do:
module Kernel
def silence_warnings
with_warnings(nil) { yield }
end
def with_warnings(flag)
old_verbose, $VERBOSE = $VERBOSE, flag
yield
ensure
$VERBOSE = old_verbose
end
end unless Kernel.respond_to? :silence_warnings
# assuming the warning is being generated when the dbi module is loaded...
silence_warnings { require 'dbi' }
I get numerous "method redefined" warnings while running an application under Merb 0.9.3. Of course, I get this only when I run my script using the ruby -w option. Is there any way to get rid of the methods getting redefined (repeated loading of files) again and again?
Has this been resolved in Merb 1?
I don't know about your issue but Merb 1.0 works great for me. I also recommend using the latest version, there are a some bugs fixed even from 1.0.x.
Whether you get warnings may depend on which ruby version or warning level you use, as can be seen in this gist.
Or maybe they fixed stuff between 0.93 and 1.0 .