I want to make a short tool that has to have access to my Google Calendar. Therefore I have to use the google-api-client gem. When I take a look to the gems installed I see it.
Before I can use the classes and methods made available with this, I have to create a YAML file with my clientID and clientSecret and a few other things. Therefore, the gem should have a cli tool called "google-api". If I now want to create this file, I always get the message google-api: command not found.
I use rvm if this is important. But I've checked if I have the right gemset availible.
(Everything I have to do, I found here: https://developers.google.com/google-apps/calendar/instantiate?hl=de)
I have got the same problems.
What version did you installed google-api-client gem ? I think you may have installed latest version.
It removed the bin file from version 0.7.0.(see here: https://github.com/google/google-api-ruby-client/blob/master/CHANGELOG.md#070)
If you need the command, reinstall with this command :"gem uninstall google-api-client; gem install google-api-client -v 0.6.4".
Related
In our Rails application we do require 'RRD' at some point, but that results in a cannot load such file -- RRD. So obviously I used homebrew to install rrdtool, but the error remains.
The docs at https://oss.oetiker.ch/rrdtool/prog/rrdruby.en.html provide two options:
Either:
$: << '/path/to/rrdtool/lib/ruby/1.8/i386-linux'
require "RRD"
In my /opt/homebrew/Cellar/rrdtool/1.8.0/lib directory there's no mention of ruby, which is because of the --disable-ruby-site-install flag in the formula, because when I skip that flag I do actually get something: /opt/homebrew/Cellar/rrdtool/1.8.0/lib/ruby/2.6.0/universal-darwin21. However replacing the path/to string with this path still gives the error.
Or:
If you use the --ruby-site-install configure option you can drop the $: line since the RRDtool module will be found automatically.
Which is a little confusing (and probably outdated) because here it seems that ruby site install is disabled by default and you have to enable it proactively, whereas in the formula it's actually actively disabled.
Either way: both options didn't do the trick for me and if there's a solution without homebrew that's also fine.
For good measure: I'm on macOS Monterey
TL;DR
For the most part, I'd say that using a non-standard gem without a Ruby version manager is your main issue. There are instructions on the rrdruby site for installing it, but they don't follow typical conventions, so your mileage will vary.
Some Practical Suggestions
The require keyword is for gems, not binaries. You need to have an rrdtool-related gem installed, available to your Ruby instance (usually through a Bundler Gemfile or gemspec, or via the RUBYOPTS environment variable or your in-process Ruby $LOAD_PATH), and then require the correct name of the gem in your code. For example, using the older rrd-ffi gem:
# use sudo if you're installing it to the system,
# but I would strongly recommend a ruby version
# manager instead
gem install rrd-ffi
# in your Ruby class/module file
require "rrd"
For the gem you seem to be using, you have to compile the gem first to make it usable, and then ensure it's available in your Ruby $LOAD_PATH (or other gem lookup mechanism) before trying to require it. The error message you're seeing is basically telling you that a gem with that name is not available as called within any of the standard lookup locations.
Again, I'd suggest reading the build documentation for your gem, and then seeing if you can install it as part of a Bundler bundle, RVM gemset, or other non-system approach if you can. Otherwise, follow the directions for the rrdruby tool, which is not available as a standard Rubygems.org gem, in order to make it available before trying to require it.
Beware of Outdated or Non-Standard Gems
Most of the RRD gems I found were quite old; most were 7-8 years old or older, so their compatibility with current Rubies is potentially suspect. The gem-builder you're using is newer, but doesn't seem to be designed as a standard gem, so you need to build it and install it in a suitable lookup path before it can be required. Installing gems as system gems is almost always a bad idea, so I'd strongly recommend building it from source and using a ruby version manager rather than following the rrdtool author's atypical suggestions. YMMV.
I have a Gem that I found at RubyForge and want to peek inside to see what code it contains. Is it possible to do this without installing the Gem on my system?
Also, if I use RVM on Mac OS X, does that at all change how my gems get installed (assuming I have one gemset)?
gem unpack unpacks the gem without installing it.
Gems on RubyGems usually have a link to the source code (most often on GitHub), in which case you can easily browse the code (I use this A LOT).
The "homepage" link also tends to link to the repository.
If all else fails, go to GitHub and search for the name of the gem (you may need to match up the authors to ensure it's the right repository for the gem).
Edit:
Just noticed that you asked about gems on Rubyforge. In which case my first step would be to check RubyGems. But otherwise you will need to download the gem and peek inside it (it's just a compressed archive so you can open it up in something like 7-zip).
Many gems have their source freely readable. The way that always works is to install it.
If you just want to browse the source; go to the gem on http://rubygems.org find your gem and use the "Source code" link.
In case of RubyForge you can find the links under the SCM link in the menu.
I'm setting up a project that uses SASS, which uses FSEvents to keep from polling the disk. It seems that this doesn't play nice with RVM, however. That means that when I run sass --watch I get this warning:
Warning: Unable to load CarbonCore. FSEvents will be unavailable.
I realize that it will still work, but I don't want to be polling my disk constantly. I want to get it working with FSEvents. The best information I could find about this was this thread:
http://groups.google.com/group/compass-users/browse_thread/thread/df7d9d0da9ec1eb1
I reinstalled my RVM Ruby (using 1.9.2) as described by Brandon Mathis and downloaded the linked RubyCocoa. However, I get an error on the first step of installing RubyCocoa:
[rvm 1.9.2] ~/Downloads/RubyCocoa-1.0.0 $ ruby install.rb config --build-universal=yes
install.rb: entering config phase...
create ext/rubycocoa/extconf.rb
create framework/GeneratedConfig.xcconfig
create framework/src/objc/Version.h
create tests/Makefile
---> framework
create /Users/xxx/Downloads/RubyCocoa-1.0.0/framework/src/objc/osx_ruby.h ...
config failed
hook /Users/xxx/Downloads/RubyCocoa-1.0.0/framework/post-config.rb failed:
No such file or directory - /Users/xxx/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/x86_64-darwin10.6.0/ruby.h
try 'ruby install.rb --help' for usage
It looks like the problem stems from this being an older version of RubyCocoa (I notice the missing file has 1.9.1 in the path), but in the Google Groups post, Brandon Mathis says specifically to use the version he links and not the newest one.
Does anyone know how to get this configured, or have a link to a recent, hopefully simpler and clearer guide to getting FSEvents working with RVM?
Versions in question:
RVM 1.2.0
Ruby 1.9.2 patch level 136 (installed via RVM)
Mac OS X 10.6.6
HAML gem 3.0.25 (SASS is part of HAML)
Thanks!
I wrote FSSM, which is what HAML/SASS/Compass use for their filesystem watching backend. While rubycocoa isn't supported in 1.9.x, the latest git version of FSSM has pretty solid support for rb-fsevent. This library currently has other limitations, like only being able to monitor one path (parent directory is a must here), but I'm working on it. ;)
I'd highly suggest installing rb-fsevent, and then FSSM from github: https://github.com/ttilley/fssm
If you have any problems, please don't hesitate to file an issue in the tracker. FSSM is a currently maintained project, and it was originally written to help Chris Eppstein out with providing watch functionality in compass (which was later adopted in sass itself). Ease of use via these libraries is my absolute top priority.
This is kind of a lost battle. You can copy the contents of the include/ruby folder from the Ruby source code to that location /Users/xxx/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/x86_64-darwin10.6.0/ which will let you run the config command, but after that you will get a lot of errors on the setup command and you won't be able to install it all. People say RubyCocoa doesn't work with 1.9.2 and I don't know if anyone managed to make it work.
I tried the FSSM method above, to no avail...
Gemfile now has:
group :development do
gem 'rb-fsevent'
gem 'fssm', :git => 'https://github.com/ttilley/fssm.git'
end
which installs:
fssm (0.2.6.1)
rb-fsevent (0.4.0)
Still getting this tho:
Warning: Unable to load CarbonCore. FSEvents will be unavailable.
Anyone have install steps to make FSSM work nicely?
With Jeweler I created a gem folder structure with ease.
However, I still have some questions:
Why are params like --gemcutter and --rubyforge still available for Jeweler. Aren't these replaced by RubyGems? Do I have to specify anything to create a gem for RubyGems?
In the Rakefile I have information about the gem, and when I run "rake install" it created a gemspec. Why is the same information in two places?
What is a manifest? Just read about it, haven't seen such file.
How do I make my gem callable from the shell once I have installed it, like rails. Cause right now it's just accessible through a Ruby script using require.
Should I use "jeweler release" or "gem push" to push my gem to RubyGems.org?
I have to specify "handle" when signing up in RubyGems. What is that?
Thanks.
jeweler was created before RubyGems became what it is, so it still reflects the split. I'm not sure when jeweler was last updated, either. (I think it also still recognizes building gems on Github, which is now disabled.)
I'm not sure I follow what you're saying. The specification in the Rakefile details what the spec that gets written should look like. The spec that gets written details what should be installed and how, I believe.
A manifest is a list of all the files that your gem should ship with. Not everyone uses one. See the hoe documentation for some pro-manifest discussion.
Many Ruby gems are only libraries. If you want yours to also have a program like jeweler or rake or rails that you can call, you have to write the callable program, put it in bin in your gem's layout and specify (in your gemspec) that it should be packaged and installed. See the Gem::Specification reference under files and executable.
Not sure. Consult both jeweler's docs and the docs for RubyGems.
You can give an email address or use a name (a 'handle', like I use Telemachus here), which is all they mean by 'handle'.
For the record, if you are just learning how to write gems, you do not need to upload your first attempts using RubyGems or anything like it. You can simply install the gem on your machine only.
I am trying to hack through a forked gem (buildr). As such I cloned it from github and began to butcher the code. The official gem is installed on my system (under /usr/lib/ruby.../gems/buildr...). There is an executable which I need to use in my dev process - buildr.
Now I want the buildr executable and the library to point to my forked repo and not the default gem installation. This would be for this gem only. As such, the changes I make against the forked repo is usable directly for testing and so forth.
I would guess I need to load my library prior to the system gem loading. Can somebody recommend the best way to do so?
I did something similar for work when the Spreadsheet gem broke backward compatibility. I put the previous versions code in it's own module and just renamed the gem my-spreadsheet and installed that (I really wanted some of the features of the new gem but I also didn't want to rewrite all my previous code at that point).
If it's just a binary you want to override you could always do some PATH magic, setting the directory of your binary first and thus make sure you always override. But personally I'd prefer making my own copy with a new name and installing that.
you could bump the version in the gemspec for your fork. Then when you install your version of the gem, it will use your (newer) version by default.
change buildr.gemspec
#...
spec.version = '1.3.4.dev'
#...
Then
$ gem build buildr.gemspec
$ sudo gem install buildr-1.3.4.dev.gem
and it should work.