I just updated my Linux box from Debian Lenny to Debian Squeeze, and now when I use Nokogiri, I get a warning message:
WARNING: Nokogiri was built against LibXML version 2.6.32, but has dynamically loaded 2.7.8
I know I can eliminate the warning message by reinstalling Nokogiri, but for now I don't want to do that because the gem is in an NFS directory shared with machines that haven't been upgraded yet. I'll upgrade them all eventually, but for now I want to know: does this warning indicate that Nokogiri will behave incorrectly on the Squeeze system, or may I safely ignore it for the time being?
It should work OK, it's just telling you there's a conflict between the versions.
The developers are interested in the users of the gem having a good experience, so they let us know when there are things going on with the system that we should know about.
It's better to have the visual noise and know what it's about, then to have the situation hidden completely and be surprised if something bad were to happen.
You might want to run some unit test code on that particular machine that exercises Nokogiri to confirm. There's always a possibility Nokogiri will try to use a call that changed or didn't exist in one of the versions of LibXML2, so you should confirm that.
If you want more information about possible issues it could have then the Nokogiri-Talk mail list is a good source. The developers monitor it and can answer any questions you have.
In Mac OSX I had to pass the libraries dirs with:
gem install nokogiri -- --with-xml2-include=/usr/local/Cellar/libxml2/2.7.8/include --with-xml2-lib=/usr/local/Cellar/libxml2/2.7.8/lib --with-xslt-dir=/usr/local/Cellar/libxslt/1.1.26
Replace those dirs with your own after installing the development versions through apt or source.
Related
I'm new to running a Linux server and slowly getting up to speed with things.
I have already installed nginx via the apt-get function, although I'm following a tutorial which recommends installing it as a ruby gem instead.
Is there any difference in the functionality/limitations to installing it as a gem than by using apt-get? - I'm worried that it won't work for non-ruby applications if it is gem installed?
Is there any difference in the functionality/limitations to installing it as a gem than by using apt-get? - I'm worried that it won't work for non-ruby applications if it is gem installed?
There aren't any limitations on the version of Nginx that Passenger installs for you. You should be able to use it with other languages as you normally would (providing you know how to configure Nginx.) I was able to use it to connect to both Ruby and Node.js sites with no problems.
The people at Phusion have a nice page explaining why they are forced to provide their own version of Nginx (rather than using the standalone one) and it comes down to the fact that Nginx does not allow to be extended at runtime. Extensions like Passenger must be compiled into it. See this page for more information on it: https://github.com/phusion/passenger/wiki/Why-can%27t-Phusion-Passenger-extend-my-existing-Nginx%3F
(Note: When I tested this I used the installation instructions from the Phusion web site https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx.html#install_on_debian_ubuntu , rather than the gem that is indicated in your tutorial, but I suspect they are both equivalent.)
I have run into this too. Where I am recommended to use one package manager over the other. I would question the age of the tutorial first, if it is not relatively recent you may want to consider if the information is no longer up to date. The libraries installed with that method may not be up to date.
However, if you intend to follow through with the tutorial you may end up needing it installed as the tutorial describes.
The difference is that one may not have all the libraries that are required or may not have the most up to date version. One tool could be buggy, I don't think this is the case in your situation but it is in Macports v.s Homebrew in my opinion. It might install to a different directory based on what install method you use, if you use a method off the web and then go back to the tutorial it could be installed to a different location then your tutorial expects.
If you have to follow the tutorial then I would all the way through, but if you don't need to use the preferred method that the program/library maintainers recommend. If the tutorial is out of date you could try to find an up to date tutorial.
good luck!
I've recently replaced an aging Mac with a new one, and so I am setting up my new environment. I installed ruby using rbenv, and have installed many gems already, but one, won't seem to install due to this error:
rdoc's executable "rdoc" conflicts with /Users/username/.rbenv/versions/2.1.2/bin/rdoc
Overwrite the executable? [yN] N
It's refinerycms of which I've built a production site on and am fairly familiar with. I thought I'd start looking at rbenv first and then look into the actual gem (not much here https://rubygems.org/gems/refinerycms that was of any help, but I'll reach out to their awesome devs next)...I was trying to see what version the refinerycms gem was using.
I appreciate any help!
Thank you, everyone,
Dinos
Try prepending yes |. This is unlikely to solve the problem but you might also wanna take a look at this issue on github where people are trying to solve the same problem:
Conflict when installing gems that have default versions
I'm using rvm on Ubuntu 12 to manage ruby versions/gemsets. I am testing various projects and some gems won't work with certain versions of Ruby or with each other. Is it possible to find which version of ruby an app was written for, so I can set my rvm to use that version and get the right gems when I run bundle install?
You can lookup the gems on rubygems.org. They are supposed to list what version of ruby they are compatible with, but that may not always be kept up to date.
If that doesn't narrow it down, you can check the gem's CHANGELOG file on github.
In the end, you may have to just try a few. There's only a handful of versions in common use, so it's not like you have to try then all.
in my experience ruby 1.9.3 is most widely supported at the time of this writing. Ruby 2.0 and 2.1 would also be good to try. 1.8.7 is pretty old and will likely give you a good bit of trouble, but it was the standard for a long time.
Maybe someone knows if this sort of RubyGems plugin exists already, before I try to sink a lot of time into writing one myself.
I'm not using RVM* or Bundler (edit: see thread in comments), so I have a big ball of system gems installed. I want to sort out which ones are gems I really want to use, which ones are dependencies that have to be there for the gems I really want to use, and which ones are just junk that can be cleaned up.
If anyone is familiar with Gentoo, I'm thinking of something similar to Gentoo's package management, but for RubyGems instead--a way to tag a small list of gems I really want to keep, then run a command that can go through all of my gems and clean up the ones that aren't dependencies of those gems. A "#world" set for RubyGems, in other words.
*RVM isn't an option for me anyway, because I have to use Microsoft Windows.
If you install graphviz, then you can runbundle viz this will produce a dot notation mapping of the dependencies and you can use that to trace dependencies down to those gem's you actually need to have installed (but only those that you have installed via bundler).
bundle viz --format=dot
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.