I've made a custom sient installer of Ruby 2.0 with some gems and extras, my installer expands all the Ruby files to c:\Program Files (x86)\Ruby, the interpreter (ruby.exe) is in the Bin folder, all is as normally but just it's not an original installation, I expand the files and I add the registry keys to associate files by my own, I can run Ruby as normally ever I want.
Now, is the first time that I try the JetBrains RubyMine IDE, and I can't found a simple guide which explains how to set the Ruby directory, seems that this IDE assumes that the Ruby installation is original and maybe takes a registry value from the original Ruby installer to know the Path or something, I don't know, but just I didn't see any help about how to set the Ruby directory manually.
(I have the same problem for PyCharm)
Anyways I've tried to set it from the Ruby SDK and Gems option, the dialog-box says "select Ruby interpreter Path", but I'm on the Path and it's not recognized, I mean that the Ok button still disabled:
Then I'm missing the right option anywhere? or really a professional and expensive IDE like this doesn't has support just to specify the location of Ruby in these circunstance where an user does not use the original Ruby installer? I really will think not.
In my experience it is more preferable to set your PATH environment variables appropriately instead of trying to locate executables on a per-app basis.
You can set your path so that the desired Ruby takes precedence over any other rubies and I am sure that RubyMine will pick it up (or just use ruby and let your PATH specify which to use).
On another note you might also want to have a look at a ruby version manager such as rbenv or RVM.
Update: Just tried to set manually a Ruby SDK in the latest version of RubyMine (6.3) and it worked as expected. I had, however, to expand the folder in which the binary resided (in your case bin), select the actual binary and then click OK. Have you tried that as well?
If you have two JRuby versions installed and one of them is not recognized:
Add both bin directories to your PATH (like in Kostas Rousis's answer above),
set JRUBY_HOME to the one version you want to use and
restart RubyMine.
In my case, I have the version 1.6.8 and 9.1.13.0 installed. Setting JRUBY_HOME to the newer version I can use both versions. However setting JRUBY_HOME to the older version, RubyMine only recognises the older version, even when I navigate to the newer version's folder. That's a really weird behavior but I'll take it. I still remember that it worked properly in earlier versions of RubyMine though (I'm currently at 2017.2.4).
Related
I'm using gem-ctags and rbenv-ctags to index my gems and ruby libraries.
Also using a few plugins that affect where Vim looks for tag files:
vim-ruby (ruby standard library)
vim-bundler (gems)
vim-fugitive (git repo)
vim-rails (Rails project)
It's great being able to jump around a well-indexed code-base, but I'm finding that Vim's 'tags' option is getting mishandled as I navigate the tag stack.
I'll start in a Rails project and find I can jump pretty much anywhere I want: within the app, into the ruby standard library (for the version of ruby relevant to the current project), or into a gem. So I jump into a gem, but then Vim can no longer find the tags for that gem, so I can't do any more easy navigation inside it.
For example: I have ruby 2.1.0 and 2.2.0 installed, and 2.2.0 is set as the global default.
Start Vim with an empty buffer from the root directory of a Rails app that uses ruby 2.1.0.
Executing :verbose set tags? shows 'tags' was last set by vim-rails.
Tags are available within the app itself, in ruby's standard library (2.1.0), and in gems (also 2.1.0).
Open a file in the project.
It now reports 'tags' was last set by vim-fugitive.
Same tag goodness as above. Fine so far.
Jump to a tag in a gem.
Now 'tags' was last set by vim-bundler, and it only includes the working directory, the current buffer's directory, and the ruby 2.2.0 standard library.
How can I make sure the tags file sitting in the root directory of whatever gem I'm navigating are found?
NOTE: I took inspiration from Tim Pope's rbenv-sentience and added an appropriate .ruby-version file to the root of each ruby installation. 'tags' still loses the gems paths when I navigate into a gem, but now it at least reflects the right version of the standard library. One step closer...
I think I got it. Part of the answer was setting a .ruby-version local to each ruby installation. This ensured that whenever I was in a subdirectory of that installation (within an installed gem, for instance), it looked to the correct ruby installation's standard library.
The main fix, however seems to be searching recursively upwards from the current buffer or directory:
set tags-=./tags,tags
set tags+=./tags;~,tags;~
As per this thread, the semi-colon syntax allows you to search upwards until a designated "stop" directory (in my case ~).
Actually, I probably only need to apply this change to the directory-of-current-buffer (./tags;~), since that'll cover 99% of my use cases.
It would also be nice if it could recognize the project's root directory and only search that far upwards, but I haven't found a way to accomplish that yet.
I am a Java neophyte and I was going to dabble with it again today when I noticed I already had an installation of the JDK at C:\Program Files\Java\jdk1.7.0_05. I just downloaded the latest version and it wants to install to C:\Program Files\Java\jdk1.7.0_07.
Why does every new revision gets its own installation directory? Are the maintainers of Java not concerned with backward compatibility and breaking things with each new revision? I could understand a new directory for the move from version 1.7.0.5 to 2.0.0.0, but from 1.7.0.5 to 1.7.0.7? That, I don't get. Can someone enlighten me?
It's not unusual to have to develop/test on multiple JDKs. The installer assumes that each JDK you install is there intentionally and does not interfere with them. Note that you should NOT be writing any code that includes the JDK path, so backwards compatibility with existing software should not be the issue. The way to set/refer to the "preferred" JDK is to use the JAVA_HOME environment variable. Most java aware applications will use whichever version is referred to by the JAVA_HOME path. There are also various OS specific ways to declare a preferred JDK/JRE. Windows uses a registry setting and Linux uses soft links.
The installer is probably just an installer and doesn't look for old versions of Java out of laziness or, more likey, they didn't want to mess with the installations you have as software, scripts, environment settings, etc, on your machine might have stored the paths to these files and may break if those files are removed.
Why should I/should I not use RVM?
I'm new to the ruby language and servers as a whole. I've had some trouble installing using RVM...so I'm inclined to not use it right now, but it seems like it may make installations down the road easier?
I'm interested to hear about your experience with RVM and your thoughts as it pertains to maintaining a server.
RVM is useful even if you don't want to install multiple versions at the same time. I'm a ruby hobbyist (PHP during the day :(), and I have no reason to want to use old versions, but I still use RVM.
Installing ruby is a pain. Getting it from the package manager (at least in ubuntu) gives you an outdated version that changes installation directories from the defaults. I've had nothing but problems with it.
So you think, "I'll just build it from source". Building from source requires getting a load of dependencies and configuring options. Often times I've built ruby only to find out I forgot to enable SSL support or readline support.
RVM takes care of all of this. In 3 or so commands, you have a perfectly built version of ruby.
And I didn't even cover how RVM manages multiple ruby installations for you, which is its killer feature. If you have that need, there is really no other sane solution.
RVM is great as this allows your to install different versions without touching your system's default Ruby install. It is rather similar to virtualenv's in Python.
Another great advantage to having RVM are the gemsets - you can create as many gemsets that are unique to the version, and patch level, of ruby.
I've extolled some of its virtues here and you should also see this blog post.
In terms of maintaining a server - let's take a Passenger install for example; do remember that Passenger is installed as a gem, so with rvm the benefit here is that you can have multiple installs of passenger, tied to a different version of ruby. Of course, typically, you'll have Passenger running on one version at a time, although there are ways to have Passenger, in particular, running on different ruby versions.
I use different Ruby versions for different projects (that's where .rvmrc is really handy). Some deployment environments are happy with 1.9, while there are a couple of legacy servers using 1.8 for some reasons. Also, occasionally I want to launch a specific version of ruby to compare how they work. RVM does all that for me.
When you are first getting used to Ruby, it may not entirely be necessary. That said, what it does is set you up for success in the future. Because once you get hooked, you may end up playing with projects that need to move from, say, MRI 1.8.x to 1.9.x. Or from 1.9.x, to JRuby 1.6.x. My experience is that this happens irregularly, but when it does, there's no substitute for RVM.
Outside of that, the other biggest feature that I use regularly, is the ability to segment one particular release. So I can have an environment for 'stable' gems, and an environment for 'unstable' gems. For instance, while Rails 3.1 has been in release candidate mode, I've had one main workspace for 1.9.2 and a separate space for Rails 3.1.rc? gems on 1.9.2. That makes it possible for me to keep developing my main Rails 3.0 stuff (with one command at the CLI), without having to specify full file paths to the appropriate rails bin files in order to use the older files.
If you're using a Debian based platform where the packagers/policy leads to a really bad default installation you'll have a way better experience using rvm.
I have Mac os 10.5.8 and Ruby 1.9.2p0, Rails 3.0.1, Netbeans 6.9.1 installed. When i run the project by creating it from existing source code, it says
Error opening script file: /usr/local/src/demo_app/script/server (No such file or directory)
Before it i have edited project in TextMate and run successfully over terminal. I know that with Rails 3.0 there is no script/server but rails server, to run the project. How to fix this issue, is there any way to configure RUN command in netbeans or any other idea is most welcome.
Thanks
I had the same problem. Here is what you can try:
Go to the folder where the gem ruby-debug-ide-0.4.6 (or whatever your version is) is installed.
In the lib folder, edit the file ruby-debug.rb
Locate the method def debug_program(options).
Look for the line bt = debug_load(Debugger::PROG_SCRIPT, options.stop, options.load_mode)
Just before that line, add Debugger.const_set('PROG_SCRIPT', './rails server')
Save file and restart Netbeans.
You may see a warning that constant is being set or something when NetBeans starts the debugger, just ignore that.
Also, you should upgrade to using Rails 3.0.3
I have read that Neatbeans 6.9.1 doesn't support Rails 3 as the underlying command line tools have changed in Rails but the changes were too late for the Netbeans release cycle.
I would recommend, if you are using MRI Ruby (1.8.*) or YARV Ruby (1.9.*) switching to Rubymine if you need an IDE either temporarily or permanently as it fully supports Rails 3 and all of the command line tools that support it. It has good integration with git too and many other very useful version control tools. If you are using any other versions of Ruby I can't say if you will have much success because I don't know.
It also has good refactoring tools and debugging support if you need it.
You can get a temporary 30 day licence from the home page and also keep up to date with development changes at the EAP page, they also offer free licenses if you are doing open source development.
For mac os 10.5.8 you might want to have a look at this thread if you have difficulty installing it.
I don't expect a bounty for this answer as its not an exact answer to your question but its a possible solution.
Would it be safe to delete ruby from my mac (the version that came preinstalled), and replace it with a link to ruby1.9, and do the same with irb and gem?
Is there anything specifically that might be an issue?
I wouldn't delete it. Personally, I downloaded ruby's source and compiled/installed it under the /opt directory. Then I edited my path so that /opt/bin/ruby (irb and gem as well) had higher precedence than the system default. This way you can keep the system default and the newest version at the same time. Plus, if Apple ever does update their MacRuby version, you don't have to worry about losing anything or getting down-graded.
I manage this with bash aliases:
alias ruby18=/usr/bin/ruby
alias ruby19=/opt/ruby1.9/bin/ruby
alias ruby=ruby19
It's occassionally handy to have both versions installed, particularly for gems that aren't 1.9-ready.
You could rename the ruby 1.8 binary files to ruby1.8, irb1.8, etc... and then symlink your ruby1.9 files to become 'ruby'. This allows you to use 1.8 if you have a compatibility issue with a project, or you could even use a tool like ruby_switcher to go back and forth between the two very easily. http://github.com/relevance/etc/blob/3d607c8ac2f76077f27c3cbc0140b04a89f546be/bash/ruby_switcher.sh
I wouldn't altogether delete Apple's Ruby. It probably wouldn't hurt anything, but it is part of the system and it's not impossible that some things might expect that version (which includes, for example, RubyCocoa) to be there.
You could, however, install Ruby 1.9 into /usr/local/bin and put that ahead of /usr/bin in your PATH, so that is the default Ruby that gets called when you say ruby.
As a side note, you might try the well-respected Ruby Version Manager. It's there to help you manage several Rubies side by side.