Why does Mac OS X come with ruby and ruby on rails pre-installed? Does the OS actually use it at all? Can I update my Ruby, Rails or Gem versions safely without something spitting the dummy?
As others have noted, OS X comes with various open source packages pre-installed. While this can be a nice convenience, the packages often are only updated to new versions as part of a major OS X release (like 10.5 to 10.6). Also, some packages are used elsewhere by other parts of OS X and there is no easy way to know which. In general, Apple assumes (and you should, too) that everything under /System/Library and /usr/, except for /usr/local/, is part of OS X and is administered by Apple. You should not attempt to remove or modify files in those hierarchies. That includes just about all of the open source packages, including Ruby.
Instead, to upgrade an existing package, the right approach is to install a new version in a separate location (say, /usr/local/) and invoke the new version by an absolute path reference (/usr/local/bin/ruby) or manipulating the shell PATH environment variable, if necessary. /usr/local/ is often used if installing directly from source. Many people prefer to use one of the 3rd-party open source package distributors, such as MacPorts, Fink, or Homebrew, each of which has its own package manager and installation locations.
No the OS does not use, it is just that Apple wants to make her products a bit more appealing to developers. (there is also Python preinstalled along with some other packets).
You can safely update your Ruby, Rails, Gems but the default Ruby version is a bit outdated. Check RVM so that you can install different Rubies in your system
Consider Rubystack if you want to play with more up-to-date environments without interfering with the existing versions. Disclaimer, I am one of the developers of RubyStack. It is freely available under the open source Apache 2.0 License.
Related
I cloned one of my 3years old project from Github to resurrect, however I'm getting bunch of migrations, gem, etc errors. Googling gives me tips about possibly using wrong ruby version.
I want to assign the specific rbenv local rubyver but I don't know which one I used and I can't find it in any settings?
Any idea how I can find what Ruby version is this project using?
There's a few places this might be annotated:
A .ruby-version file, though these are often ignored to avoid friction between developers with slightly different versions. This is what rbenv uses, as well as other tools like RVM.
The Gemfile can have a ruby version lock in it, though this is usually a minimum requirement, like >= 2.3.0.
The README if the developer is kind.
Otherwise, there's no real way to know.
It's worth noting that Ruby 2.0, 2.4 and 3.0 are often the biggest upgrade hurdles, so it's worth trying with the latest version you can get away with, like 2.7.2 if practical, 3.0.0 if possible.
I'm trying to learn Ruby On Rails, and found I can't really use Ruby 2.2.2 because Nokogiri doesn't support it on Windows yet.
How do I roll back Ruby to an older version so I can develop on an older framework while I wait for Nokogiri to come up with a product for Windows and Ruby 2.2.2?
What is the best way to uninstall it so I don't have bits hanging around that might cause issues?
This is in response to my question: "Error installing "nokogiri" in a Ruby on Rails application?"
Linux users: please remember that not everyone is interested in switching their OS, running 2 machines, trying to figure out dual boot, or dealing with virtual machines dragging down a host. While Linux is a great environment for software development, people, like the OP, just looking to try their hand at something (like ruby/rails) should not immediately be told to switch to something completely unfamiliar which might not even adequately support their normal day to day activities.
Since I am not a believer in making anyone leave an environment they are comfortable with (especially since you stated "learning". Why would you want to make an additional investment just to try something out?) and because I did not want my comment to get over looked as it will help with your issue, I have decided to post this as an "answer".
Mac and Other *nix based OS's have the ability to install rvm (Yes I know there are more but rvm is my personal choice and a community favorite) which allows you to manage different versions of ruby on the same OS.
While rvm is not available for Windows there is a small application called uru which will get you as close from a windows standpoint.
Installing a version manager means that you do not need to uninstall or rollback anything you can simply install a new/old ruby version side by side the current versions you have and switch between them fairly easily from command line.
While uru does not have all the fancy features that other applications like rvm possess (by design). It contains the important ones (primarily in your case switching ruby versions). The CLI is very simple and straight forward. Examples of uru Usage
Also: Please note I work in an Windows centric Office and have developed more than a few fully functional rails applications on a windows machine. Yes there are some headaches when dealing with native extensions and know that you will always be slightly behind the leading edge for ruby and rails but it is completely possible and feasible to build enterprise level web applications completely in a Windows environment without ever installing Linux at all. (Note I do use dedicated Linux machines for non development web servers)
Go to your control panel and find the ruby or rails installer. Uninstall it. Go to your file explorer and make sure the folder is gone.
Now go to http://rubyinstaller.org/downloads/ and pick an older version. Follow that process just like the first time you installed ruby. Then go get nokogiri and whatever other gems you like and enjoy.
I had the exact same issue when trying to some gems(stanford core nlp & treat) to work that relied on JVM that was 32bit instead of 64 like the version of ruby I was running so I reverted to 1.9.3.
I'm also in the avoiding moving to OSX or linux camp so I feel your pain man.
Let me know if this works and good luck!
I'm writing a script that will install some of the optional postgresql modules. Is there a way to programmatically figure out where the contrib directory is or do I have to prompt for the path? I've looked at a few examples and it seems inconsistent; doesn't appear in pg_config.
(The script might be run on OS X or linux, and I can't make assumptions about how postgresql was installed).
There is no easy works everywhere answer to this, so it's a matter of how much intelligence you want to try and put into your installer. And for some people it will be impossible to do what you hope for, the best you'll be able to do is offer guidance about what's missing. There is a lot of variation on packaging here between Linux distributions, versions of PostgreSQL, and the various ways you can install PostgreSQL on OS X (MacPorts, homebrew, etc.)
First off, only source code installs will have a contrib directory with source code in it that allows building the optional modules. In the packaged builds for Linux, all the contrib binaries may only be available via an optional package, called something like postgresql-contrib. That's the only way to make the optional modules that come with the database available: install the package the binaries are included in. You may see some variation in the OS X builds here too.
If you want to install extensions (what these are officially called as of PostgreSQL 9.1 now, rather than 'modules') using binaries you provide instead, what you then want to know is where to put the resulting shared libraries and matching SQL files that reference them. What pgconfig returns for pkglibdir will tell you where the binaries go, while sharedir points toward the default place to put the SQL. Providing binaries is a losing game though; the job of syncing with every platform to build them is a huge one.
And here are the sort of additional complications you'll run into in this area, if you wanted to ship source code and try to build things yourself in an automatic way:
PostgreSQL 9.1 now installs these using the CREATE EXTENSION
mechanism, so you'll need to handle both the pre-9.1 method and the
new one introduced there.
Not all PostgreSQL installations will have
pg_config. It's considered a development tool, and which package it
gets bundled with (and whether that package is mandatory or not)
varies. Debian/Ubuntu put it into the optional liqpq-dev, RedHat
derived RPMs have it in postgresql-devel or
postgresql-[version]-devel.
Due to pg_config being necessary for
compiling the new 9.1 extensions, packagers have started
reconsidering where pg_config goes; it's considered a lot more
important now than it used to be. 9.1 or later packages might alter which package it's contained in. That doesn't really change what you can and can't do though. It just impacts what advice you might offer for correcting situations your program can't deal with.
I've been describing the standard
Linux packaging here when I talk about that OS. There are also installers for both Linux and
OS X from EnterpriseDB, what they call their "one-click installers".
These use a different standard altogether for what people do and don't get installed in this area. I don't follow the commercial packaging to know what is actually different, but it's another variable you can expect people to encounter.
Recent OS X versions may
have some system PostgreSQL components floating around too. No idea
yet how this handle extensions though.
Basically, all three of version/packager/platform can vary how this will work, and the idea that you'll find any solution that handles even the majority of those permutations is optimistic. Installing extensions is known to be difficult in PostgreSQL, which is one thing that motivated all the 9.1 changes to turn it into a simple CREATE EXTENSION for many of them. But for now, those changes have just added another whole set of variation into the mix, actually making this harder during the transition period. It will be a while until PostgreSQL versions supporting that are the only ones in popular use.
I'm using Netbeans and JRuby to develop a Rails web application.
But for deployment, I will be using Heroku.
Since Heroku uses the Ruby-C implementation, I was wondering my use of JRuby can cause problems? Is this approach a safe thing to do?
You can develop in NetBeans and use C-Ruby (aka MRI Ruby). Just install Ruby separately, go to Ruby Platforms, and select it. I highly recommend you install a separate Ruby anyway, whether or not it is MRI Ruby, because if you use the built-in NetBeans version of JRuby (which is often not the latest) and then upgrade NetBeans, you'll lose all the gems you've installed. Installing Ruby/JRuby outside of NetBeans helps you to better manage the versions and gems.
Now to answer your questions: Likely you will not encounter problems with basic Rails applications. If you ever have the need to use non-native libraries you may run into issues. Some gems (e.g. Nokogiri) have a C version and a Java version so you'd be OK, but if you wanted to use a plugin that relied on RMagick, for example, you'd struggle, as you'd probably go a different route if you were developing and deploying with JRuby.
Bottom line: I wouldn't recommend it. I'd recommend using the same platform for both. But you can use MRI Ruby in NetBeans.
funny thing: I stumbled in your question while looking for a tool chain to do it the other way round (developing in MRI Ruby, deploying with JRuby). Of course you can not use any Java classes and internals, but this for sure is obvious to you. According to my results thus far you shouldn't encounter any process structural issues, because MRI Ruby adheres to the shared nothing principle whereas your requests in the development app share the VM at least. Maybe to be shure you should hae a look at http://kenai.com/projects/jruby/pages/DifferencesBetweenMriAndJruby and read it in a reverse sense, especially the "Native Endian is Big Endian" paragraph when un-/packing Strings or Arrays.
You will save yourself a lot of trouble if you develop on the same platform as you deploy. This goes for OS as well, especially Windows then deploying on Linux, less so with OSX, but still sometimes an issue. You will be troubleshooting on your deployment system and that just isn't the same as catching something as you code it in development. I recently started using JRuby for a project and there are quite a few differences and different gems altogether in some cases.
As for loosing installed gems etc. take a look at using Bundle while you are at it, that will also save you some trouble down the line with gem versions out of sync.
I'm in the process of deploying a rails application to Windows machines. I do all of my development with OS X and Linux, but the final app will actually run on Windows machines.
That said, my client is looking for an all-in-one Apache(I had to talk him out of IIS)+Rails+Application deployment/installer. He wants to hand all of his (Windows-based) clients an install CD for their respective servers (they all want their own setup).
Is there anything like this in existence? I realize Capistrano exists but that requires a great deal of setup on the hosts (especially for Windows) beforehand and it's not very feasible in this particular case.
In the past I've used InnoSetup (http://www.jrsoftware.org/isinfo.php) for creating installers, but I'm not sure that's going to work in this case.
If you guys have any input, suggestions, or highly persuasive client techniques (to talk them all out of Windows =P) it would be most appreciated.
Best.
Try with RubyStack:
BitNami RubyStack is an installer that greatly simplifies the installation of Ruby on Rails and its runtime dependencies. It includes ready-to-run versions of Ruby, Rails, MySQL and Subversion as well as a number of third-party libraries like FiveRuns TuneUp. RubyStack is distributed for free under the Apache 2.0 license and has been packaged using BitRock's multiplatform installer.
http://bitnami.org/stack/rubystack
I'd look into using jruby with glassfish. Make sure the users have java and it should be good to go.
RubyStack is the closest thing to what you're after, although you might need to tailer the install a bit and remove some unwanted baggage. I don't know of any other Windows projects for a production environment (InstantRails is designed for development).
Maybe you can make InstantRails meet your needs.
Ruby and thus Ruby on Rails is a fairly notorious deployment on Windows even in the best of circumstances, moreso when the setup is out or your hands like that. I don't mean to admonish, but this definitely speaks to matching development and deployment enviroment (I once ran into similar problems when I found out that the Java enviroment we were deploying to was a good half-a-decade out of date).
As I don't have enough Ruby-on-Windows experience to fairly weigh in on the matter, I'd say either LiveCD's or CygWin deployments may be worth looking at (Always good to broaden people's view on alternate Operating Systems, right?).
Have you considered building a single version that runs in a VM?
For this particular problem, I'd go with a traditional Windows installer package like NSIS.
When I had a client with a Windows-only IT department, though, I found they were much more amenable to an XServer than a linux server. I don't generally think of OS X as a server OS, but it actually worked really well. I tried for linux first, and when they shot it down, I suggested OS X and they jumped at it.
It helped, I think, that they already supported some Mac laptops.
Good luck!
As other posters have suggested, RubyStack should be a good option. It is free and you can always use it to run your own 'post install' scripts to customize it for what you want. If you want a supported stack or addition/modifications to RubyStack you can get commercial support from BitRock We have done so for several Rails based companies that wanted a local version, including for the guys over at GitHub