after I finally managed to get Compass running on my hosted web space (no root access), there is a new problem when trying to install bootstrap-sass:
$ compass watch
LoadError on line 31 of /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: no such file to load -- bootstrap-sass
gem install bootstrap-sass
ERROR: Error installing bootstrap-sass:
execjs requires Ruby version >= 1.9.3.
Well, it is quite obvious what's going on: I need Ruby >= 1.9.3 while the server only offers 1.8.7. I already checked: It is not possible to use another ruby version on this server.
Is there any way/hack/solution to use bootstrap-sass?
When a gem depends on a specific (or newer) version of Ruby, then the reason is usually that the gem depends or uses a feature that did not exist in older versions.
There are many differences between Ruby 1.8.7 and 1.9.3: The new hash syntax, better UTF8 support and new methods or methods with changed behavior - just to name a few.
When a gem was build for 1.9.3 and you want to use tat gem with an older version, there is IMHO only on option: Fork that gem, review the source code and rewrite everything that is not compatible with 1.8.7.
You will very likely learn that such gems depend on other gems that also depend on more up-to-date versions of Ruby. Do the same for that gems...
I totally agree that still using Ruby 1.8.7 is not a good idea. I am not sure why my hoster still uses a version this old, but it is simply a fact I cannot change. Sure, I can move to another hoster but for now I was able to find a working solution. Maybe someone else has the same problem. So this worked for me:
gem install bootstrap-sass did not work because it requires execjs and the latest version requires Ruby > 1.9.3. Gladly bootstrap-sass does NOT require the latest version of execjs. So the solution is simple: Install a previous version of execjs which is happy with ruby 1.8.7:
gem install execjs -v 2.5.0
gem install bootstrap-sass
Related
I currently have 2 ruby versions, 2.5.5 and 2.3.8, I am managing them with rbenv, and for gems, I use bundler to manage my specific gem versions. I have an issue when I want to switch to a project that uses 2.3.8 or a version that has to do with Ruby version 2.3.
My question is how do I get bundler to run the command to bundle install interact with my 2.3 projects.
My current version of bundler is 2.0.2.
I have already tried installing a lower version of bundler of which the bundler website claims to interact with ruby version 2.3.
I thought that if I specified the command to run bundle _version_ install it would work, but it still gave me the response that it needed ruby version 2.5 for bundler to work.
Lots of help appreciated.
In some situations, isolation can help. I would like to recommend rvm (https://github.com/rvm/rvm) for managing ruby versions. This tool is very similar to rbenv but in comparison, it allows you to create gemsets which are kind of containers of gems for special purposes. For instance:
rvm install 2.5.5 --disable-binary
rvm use 2.5.5#name-of-gemset --create
gem install bundler
bundle install # inside your project folder with Gemfile
I think that you will not have problems with versions again.
I am using puppet to install ruby 1.9.3 as the system ruby on an Ubuntu Trusty Vagrant container. I also install Bundler. I am told that "gem" is installed as part of the installation of ruby.
How do I know which versions of gem go with this version of ruby?
How do I know which versions of bundler go with this version of ruby?
Here is a fragment of puppet code:
$other_reqs = [
...
'ruby1.9.3',
'ruby-bundler',
'rubygems-integration',
...
]
package{ $other_reqs: ensure => 'installed'} -> Package['percona-toolkit']
The package declaration will default to using apt-get to download packages. Clearly the line with 'ruby1.9.3' will get the 1.9.3 version of ruby. It also installed gem 1.8.23. Is this a compatible version of gem? How do I know?
The line with 'ruby-bundler' installed Bundler version 1.3.5. Is this a compatible version of Bundler? Or should I indicate a specific version in my requirements array? Where ought I look to find this information?
It might be helpful if you indicate the problem, or what you're trying to do. Nevertheless:
gem is a command that is built-in in ruby from 1.9+, so whatever comes installed with Ruby should be fine.
bunlder is a RubyGem, normally installed by doing gem install bundler. You can specify the version by doing gem install -v <version>. Either it gets installed correctly or you get an error. Can you install bundler doing that?
And lastly, unless you need it for a specific reason, 1.9 is very old :)
I am currently managing an installation of ruby 1.9.3 in red hat 5.
I have found that, during a specific gem install, ruby is trying to download and install the latest version of a particular required gem.
I have attempted to prevent the updating of gems using the --conservative flag, however, this does not seem to work.
The gem in question requires a specific version of launchy which, in turn, requires a specific version of addressable.
The versions of these gems that are already installed meet the requirements of the gem I am attempting to install. However, the gem command attempts to download and install the latest version of addressable.
This is a problem, because the latest addressable requires public_suffix, which only installs in ruby 2.x and greater.
The gem that I am trying to install is a custom gem, and thus I have modified the gemspec, and found that removing the launchy requirement fixes the issue. However, launchy is a required gem, so the requirement needs to stay in the dependency list.
Has anyone had any experience with dealing with this particular version of ruby and gem and found issues with dependencies?
I have tried going in and modifying gemspec for launchy and addressable in the installed gems dirs, but have found that the issue is with the gem install command attempting to update/install the latest gems despite giving it flags telling it otherwise.
ruby 1.9.3
gem 1.8.23
After some additional research prompted by the above responses, it was determined that an outdated version of Hoe was causing the generated gem to try and install the latest dependencies. After moving away from Hoe to manage dependencies and versions, my issue has been solved.
Some of the dependency management classes seem to behave quite differently, so that's probably the first place to look.
Use the -v flag to specify the exact version to install:
gem install your-custom-gem -v 1.1
When I install gems using Bundler to the project directory, for some reason it installs them under the Ruby version namespace, that is vendor/bundle/ruby/2.1.0.
Why Bundler have such behaviour? Is there any way to prevent Bundler to install gems under the Ruby version namespace and instead to place them directly into vendor/bundle?
Bundler does this for the same reason that rubygems does it - different Ruby distributions may not have compatible gems. For example, a gem with a C extension built against 1.9.3's ruby.h isn't going to work under 2.1.0, and neither will run under JRuby. Pure Ruby gems should work, but there is no differentiation made between pure Ruby gems and gems with native extensions in Rubygems or Bundler, so the system behaves conservatively. Additionally, some gems specify required_ruby_version in their gemspecs, which locks them to a particular Ruby version or versions; support of that sort of feature requires namespacing.
While you could probably monkeypatch things to get the behavior you desire, it wouldn't be very advisable, since C extensions running against the wrong Ruby version would likely result in your process segfaulting.
What version of Ruby should I be using on a windows environment?
I'm trying to use Watir on 1.9 and it does not work. Will work on 1.8.6.
Any recomendations on which version to use and reasons why Watir does not work on 1.9
Watir.com recommends using Ruby 1.8.6-26. I have not tried it, but there is a fork of Watir that claims to be compatible with Ruby 1.9:
http://github.com/vapir/vapir
I use this one and it works:
>ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
There's no "correct" version. 1.8.6, 1.8.7 and 1.9.1 are all officially "recommended", which is not much help!
When 1.8.x gems don't work with 1.9.x under Windows, it's often the case that the gem - or one of its dependencies - includes a compiled element (a DLL, usually named with a .so extension) and that this component hasn't yet been compiled against mingw32, which is the standard for Ruby 1.9, whereas 1.8.6 and previous versions were compiled with the (old) MS Visual C.
Looking at the watir gem, I see it includes win32ole.so, which could be the problem. I'm not sure why that should have been necessary - it's part of the installed set for Windows. Perhaps the developers needed to ensure a fixed stable version so they forced a particular version rather than use the one from the library. Or maybe they fixed something? Dunno.
Beyond that, watir also depends on win32-api and nokogiri, both of which installed mswin32 versions on my machine and will need to have mingw32 versions to work with 1.9.
Not having a 1.9 instance to hand, I can't quickly tell if these versions exist.
Try looking for a mingw32 version of win32ole.so (probably somewhere like [ruby-dir]/lib/ruby/1.9/i386-mingw32) and putting it in place of the one used by watir.
It's best to use the mingw versions of Ruby as supplied with the RubyInstaller. The older mswin32 versions of Ruby are considered legacy. Some gems need to be compiled from source (RedCloth being a good example) and for this you'll need to install the DevKit; however, watir doesn't need anything to be compiled - all of its gem dependencies come pre-compiled with mingw32 extensions (nokogiri and win32-api).
You can install multiple versions of Ruby (including JRuby and IronRuby) on Windows using Pik. Once you've installed the Pik gem, you can easily install new versions of ruby by issuing commands such as pik install ruby 1.9.1 or pik install jruby. You can even do pik install devkit to install the DevKit for all installed copies of Ruby. Documentation and lots of examples of use can be found here.
To allow Watir (and FireWatir) to run on ruby 1.9.2
install devkit and follow procedures listed here : http://rubyinstaller.org/downloads/ Ruby Installer at GitHub
gem uninstall win32-api
gem install win32-api --platform=ruby