During testing in chapter 3 I get the following warning, is this ok to ignore?
RubyDep: WARNING: your Ruby is outdated/buggy. Please upgrade. (To disable >warnings, set RUBY_DEP_GEM_SILENCE_WARNINGS=1)
Run options: --seed 18589
I'd say yes, it's okay.
...for as long as you're following a tutorial that was staged on specific versions of Ruby, Rails and other libraries. What's told in the tutorial was likely tested on these and works even despite the software being "outdated/buggy".
Depending on how ready you are to resolve sudden issues and deal with changes as the result of upgrading anything...
You can either go for using latest versions now and expect the outcomes to diverge from what's given in the tutorial...
...or strictly follow the tutorial and use outdated versions until the tutorial is complete and there are no more directions and expectations.
In contrast to above answers I'd suggest you to update the Ruby to latest version because I had same error when I revisited sample app and without updating I was not able to run tests. So just follow these simple steps and update Ruby to latest version:
As stated by Mo H., install RVM first.
and the upgrade it to 2.3.1.
Also after upgrading, make sure to check the ruby version using ruby -v and if it still shows ruby-2.3.0 then run
rvm use default ruby-2.3.1
This is really dependent on what version of ruby you are running. In general it might be fine to ignore it, but if I were you I wouldn't risk it. Your best bet is to install RVM. This will allow you switch between ruby versions, so you can swap to a newer version of ruby and make sure everything works as it should and see if the warning goes away.
Warnings are there for a reason, and while you can ignore them, it can come back to haunt you later. When its something simple like this its better to just deal with it.
Related
I brew install --HEAD'd node recently to see if the upstream version fixed a bug I was experiencing. (It did!)
Now I'd like to downgrade back to the stable, bottled version. Is there a simple command to do so?
brew reinstall simply pulls & rebuilds the HEAD version from upstream. (Where does Homebrew "remember" my HEAD preference?)
brew uninstall --ignore-dependencies && brew install is of course possible, but annoying given that it would also delete my build history & install receipts, which I'd like to keep around a bit if possible.
I did the same thing for pyenv while waiting for version 2.1.0 to make it into homebrew-core. I figured I'd simply uninstall pyenv and reinstall it without --HEAD, but when I attempted to do so, Homebrew told me:
Only uninstalling HEAD version because multiple versions are installed
(Or something like that.)
The documentation doesn't really explain this, as far as I can tell, but I did find an explanation here:
uninstall first removes whichever version is "active", i.e. linked into the main prefix. What happens when you run uninstall again depends on how many other versions are installed: if there is only one, it is removed, otherwise it errors out because it doesn't know which one to uninstall (unless you pass --force).
So I didn't need to do anything else, aside from delete the pyenv repository that Homebrew cloned under ~/Library/Caches/Homebrew/pyenv--git. (I think the fact that it doesn't remove this might be a bug.)
Now, if you first uninstalled node stable, then installed HEAD, your situation might be different.
(I know this might not be a great answer, but it's too long for a comment.)
I'm hoping that WSL2 solves these problems and makes this question obsolete in the next 6 months or so, but in the meantime, I don't feel comfortable running bleeding edge or other preview releases of Windows on my primary laptop.
Sometimes, when I'm installing Ruby gems (bundle install or bundle install --path=vendor/bundle) inside of WSL, I get Permission denied errors when installing a gem with a native extension.
The most recent incarnation of this error was this:
Permission denied # rb_file_s_rename - (./.gem.20191006-12131-11th7ub/byebug, /home/thomasowens/project/vendor/bundle/ruby/2.6.0/extensions/x86_64-linux/2.6.0-static/byebug-11.0.1/byebug)
To resolve it, I simply deleted /home/thomasowens/project/vendor/bundle/ruby/2.6.0/extensions/x86_64-linux/2.6.0-static/byebug-11.0.1/byebug, reran the bundle command, and it succeeded. Sometimes, I need to do this multiple times, but it usually works.
In the end, I can get all of the gems installed properly, but it's hard when setting up a new project and there are many gems with native extensions. Same when I'm introducing a new gem or updating a gem that causes the native dependencies to need to be updated.
I haven't found much about this issue, but I'm wondering if there is something that I can do to alleviate the pain of needing to run bundle install multiple times to get a project set up and running under WSL.
The problem that I'm experiencing may be related to Visual Studio Code's file watching. It is reflected in two GitHub issues against WSL - 1956 and 3395. Visual Studio Code has remote.WSL.fileWatcher.polling, which can be enabled which works around this issue. However, the documentation states that there is a performance impact for large workspaces and it may be necessary to also adjust the remote.WSL.fileWatcher.pollingInterval setting. WSL2 will resolve these issues.
Since enabling this flag, I haven't seen the error while working with VS Code running.
Now that WSL2 is out, I was able to disable this flag and the issue has not reappeared. It appears that if you can upgrade to WSL2, that may be a preferred solution. However, for anyone who hasn't yet upgraded or can't upgrade, toggling the remote.WSL.fileWatcher.polling and remote.WSL.fileWatcher.pollingInterval should be good.
I'm about to install ruby for an application I am developing is there a particular reason I should do the latest stable build or is 1.9.3 going to be fine for my application? (it's a simple Rails app that will call a mongoDB with some queries visualize data, download it do some analysis) What are the primary advantages to using 1.9.3 over the latest build?
Simply for safety reasons, support and updates I would decide to use the newest stable release for a new project. That's my opinion and suggestion.
The project I've been working on needs to upgrade it's grails version from 2.2.3 to 2.5.1. Needless to say, the project is huge and I am sure there will be lots of issues while upgrading.
What are the precautions needed while upgrading? And what are the changes required in the dependencies below:
dependencies {
runtime 'mysql:mysql-connector-java:5.1.34'
compile ('ar.com.fdvs:DynamicJasper:5.0.0')
compile ('org.apache.poi:poi:3.10-FINAL')
compile ("com.aspose:aspose-words:14.5.0")
compile ("com.aspose:aspose-cells:8.4.2")
}
As well as in plugins below:
plugins {
compile ":aws-sdk:1.6.7"
compile ":export:1.5"
}
You can find the high level changes listed for each major release up to 2.5.0 in the 2.5.1 documentation.
You will need to note all of the features which will change during the upgrade, identify where you are using them and plan how you are going to migrate.
What I usually do when upgrading the Grails version (apart from reading the upgrade sections of the version I'm upgrading to and all in between major versions) is create a new empty application with the new Grails.
And then use a tree compare tool (like meld) and compare all the build and configuration files to see what has changed.
This way you get most of the needed changes without much trouble. You still need to test your application thoroughly. Hopefully you have lots of unit and integration tests to help you with that...
I'm trying to run a Grails Application from the Grails In Action website. I've imported the 'hubbub' project into the GGTS app and have encountered build errors. The project was originally built with Grails 2.3.7 whereas I have version 2.4.4 on my system. Based on another Stack Overflow question I've changed the 'app.grails.version' in the application.properties file to grails version 2.4.4 which prompted a flurry of downloads in the command prompt terminating in a series of errors regarding problems with plugins. I can't run the app because I'm told that "Project 'hubbub' is missing required source folder: grails-app/utils". If I try to change 'app.grails.version' back to 2.3.7 I'm told that I need to configure a Grails installation of 2.3.7.
Am I doing something wrong here in trying to upgrade this Grails project? Or do I really have to install Grails 2.3.7 in order to get this to work?
(Sorry, I haven't posted the errors regarding plugin downloads but I can't seem to recreate them).
Thanks in advance!
Grails 2.4 is a big change over 2.3, mostly due to the use of the asset pipeline instead of resources.
Also simply changing the version in application.properties isn't enough, you also need to actually run the matching Grails framework.
See here for upgrading an app from 2.3 to 2.4: http://grails.github.io/grails-doc/2.4.x/guide/upgradingFrom23.html . From experience upgrading Grails apps from older versions must be done manually. One reason is that the upgrade command is obsolete and has been removed. Read the docs for breaking changes and address each change individually in the code. Upgrading patch levels are no problem (usually), but upgrading minor and major versions often are a lot of work.
Since you are learning, I would stick to 2.3.7 for your exercise (meaning that you must run 2.3.7, which you aren't doing). What you'll learn will remain valid. Do use 2.4.4 when building your own project from scratch.
If your project only missing grails-app/utils, try just to create it.
Take a look in your Project Properties -> Build Path. There are all the source folder defined. It can be helpful