I have just installed Sidekiq into my Rails project. Unfortunately, Sorbet doesn't like it. For some reason it thinks that Sidekiq::Job is a class instead of a module and so it keeps throwing the following error:
Either the RBI files for Sidekiq are out of date or something else is amiss. Unfortunately it's almost impossible for me to update RBI files right now because doing so generates literally thousands of errors elsewhere which I do not have the bandwidth to fix.
So my approach to solving this was to changed #typed: false to # typed: ignore. This does solve the errors in the tracking file...
However as soon as I do that, any upstream files that reference this Tracking class start complaining that it doesn't exist (even when the upstream file has # typed: false:
This feels like being in the most frustrating Catch 22. I can't currently figure out how to install Sidekiq without either trying to upgrade all of the sorbet installation or alternatively switching sorbet off entirely.
How can I make Sorbet see an ignored class?
How can I make sure that Sorbet can see my class even when typed is set to ignore?
Not an answer, just a suggestion :)
My guess is that you're trying to use sorbet-typed with the latest Sidekiq. There was a relatively recent change in Sidekiq (so now Job is a module) that is not reflected yet in the sorbet-typed definitions...
I'd say there are 2 options:
(better) Update sorbet-typed to reflect the recent Sidekiq changes
Use older Sidekiq
Related
So I started working on my first open-source contribution in ruby. There I have the library I'm working on in the /lib/ folder. Now when I tried changing the code, my program (which uses the library) still uses the old code.
For example: Broke a function on purpose by deleting its end keyword (which should be causing an immediate crash), but it kept working perfectly after I did.
Another example was changing the code in such a way it should still work (mutating the output string) but it still returned the old string.
user~$ bin/ruby-hyphen -V "this is a test sentence"
this is a test sen-tence
Does anyone know if I have to tell the runtime to refresh it or something along those lines?
I found out why that happened. The file has a *.gemspec, which made it act as if it was a gem. To see the changes I needed to enter:
gem build *.gemspec
bundle exec rake install
Or, if you want to develop quicker: change everywhere you require it into a require_relative. That should also fix it. I hope this question helps someone in the future!
I have a gem I want to add types to (either by submitting a PR or by forking to use just in my project), but the documentation does not give any more guidance other than to create an /rbi folder.
Thinking out loud, should it mirror the files in lib/ with added type signatures, or should it be one large file (per version?) like the signatures in sorbet-typed?
I don't know of any gems doing this yet, and the documentation doesn't mention it either.
I recently went through this process for one of my gems - pdf-reader. It was my first experience with sorbet (so I'm no expert), and I also noticed the lack of documentation for the specific use case of adding types to a gem.
I ended up generating the initial rbi file using parlour, which put them all into a single file: https://github.com/yob/pdf-reader/blob/480aa240a531cd6f97a46a29279f19025821e886/rbi/pdf-reader.rbi
Sorbet seems happy with that, so I haven't changed it.
I have done a bit of digging through the rubygems code and it doesn't look like there is a built-in way to get it to not throw a Gem::ConflictError even if there is one. During development I might be wanting to test something that I know is not going to touch the code from which the conflict is coming or I know that the whatever version of the erstwhile conflicting gem isn't going to cause a problem. I just want to get on with testing what I want to test and I'll worry about version conflicts later.
I know I can hack rubygems to do this. I can think or multiple ways to get it done. I'm just kind of curious if anyone has already done this, how they did it, and maybe if that code has been shared somewhere. I'm also a bit curious as to why this isn't built in to rubygems as a development tool.
You need to worry about version conflicts now before you can get anything done. As Ruby has a singular root namespace and every dependency gets loaded there it's generally not possible to load multiple versions of the same gem. Other systems like NPM for Node.js are significantly more flexible, it's possible to load any number of versions at the same time, so if you're used to that you'll need to adjust your expectations.
If you're trying to do testing and you want to avoid resolving a conflict, just remove that gem requirement from the Gemfile temporarily.
Ultimately you'll have to fix things, there's no way around it, but you can always be selective about what you require.
If you really know what you are doing, try this:
export NOEXEC_DISABLE=1
ruby you-program.rb
This environment variable will disable search and check for Gemfiles and gem versions.
After many searches via Google I'm ready to get some input from the community. I'm trying to apply for App Academy in San Francisco and one of the required pre-work is TestFirst's Learn_ruby. I original had this configured on a Linux VM on my windows box. It worked very well. When I ran rake it would list one problem at a time; the text was is helpful colors; and the output was very condensed so I only got what I needed to read. I've recently wiped and configured my system as a dual boot Xubuntu 14.04/ Windows and the VM I once had is long gone. I worked to get Ruby setup in my linux vm just as I had done in the VM.
My problem now is when I run rake on my projects I get the same depreciation warning:
Deprecation Warnings:
Using should from rspec-expectations' old :should syntax without
explicitly enabling the syntax is deprecated. Use the new :expect
syntax or explicitly enable :should instead. Called from
/home/kaji/Projects/learn_ruby/05_silly_blocks/silly_blocks_spec.rb:25:in
`block (3 levels) in '.
After googling this back and forth I understand for the most part what the error is telling me. And I've even found a solution to get it to go away. Thanks to this post: RSpec's New Expectation Syntax, I was able to find a syntax to make the warning go away. (basicly had to change blah.should == # to expect(blah()).to eq(#) inside the *_spec.rb file. This seems to make the warning happy. However I still see signs that I have another problem.
The output isn't as 'friendly' as it was when I was on my VM. It's not in color; it dumps all the errors at once. What I enjoyed the most about learn_ruby was it gave me one objective at a time with minimal output. Now i have to scroll up quite a ways just to see what my issues are.
I've tired removing RVM completely and all gems and reinstalling to see if I could resolve this. No dice. I'm such a Ruby Noobie i'm a little overwhelmed with all this. I'd like to just get back to learning the basics but this has been troubling me for over a week. Has anyone had this problem/fix the except
I've also tried removing the rpsec ~<=2.0 from the Rakefile. I'm using ruby -v 2.1.2, rails 4.1.1 and i have RSpec 3.0.0, 2.99.0, 2.0.0. I even tried finding a tutorial on changing the syntax but it was real confusing as it introduced lots of Ruby concepts I have no idea on. At that point I feel like I'm over my head and there is something simple I'm missing.
Hope I provided enough info for assistance.
I hope I'm answering the correct question, since you seem to have figured out the one in the title (i.e. the preferred syntax having changed from blah.should to expect(blah).to). It would help if you changed the title to reflect the actual question.
RSpec.configure do |config|
config.fail_fast = true
config.color_enabled = true
}
will make RSpec fail at first error, rather than after running all tests, and enable the colours, for that one file.
Or you can run rspec with rspec --fail-fast --color.
Alternately, you can put this in $HOME/.rspec so it always does it:
--fail-fast
--color
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"