I'm having what seems to be some very basic problems getting started with Gem development in ruby.
I've created a new project with this command.
bundle gem foobar
I can now run
bundle && bundle exec rake spec
and everything is fine.
However I try to add a new part to my spec
expect(Foobar::BAR).not_to be nil
and then define this in ./lib/foobar/error.rb
module Foobar
BAR="bar"
end
It just does not find this file. Error is NameError: uninitialized constant. I can require_relative in spec_helper.rb but that's clearly not right or sustainable.
I've seen the issue here Missing File in Gem after Build I've added the new file to git. That does not help, adding the files directly in the gemspec file does not help either.
The whole project is here https://github.com/ollyjshaw/broken_gem
What am I doing wrong? It's gotta be something trivial, but I can't see it.
Answer:
Answer is in Antony's comment
"You're not requiring your error file when your gem is loaded: github.com/ollyjshaw/broken_gem/blob/master/lib/foobar.rb#L1"
"You'd load your main module and that module would load other modules/classes it needs and down the tree it goes"
Typically you'd add all the class/module files to the load path in the spec_helper.rb file:
$LOAD_PATH.unshift File.expand_path("../../lib", __FILE__)
require "your_gem"
Related
Is there any major difference between load and require in the Ruby on Rails applications? Or do they both have the same functionality?
require searches for the library in all the defined search paths and also appends
.rb or .so to the file name you enter. It also makes sure that a library is only
included once. So if your application requires library A and B and library B requries library A too A would be loaded only once.
With load you need to add the full name of the library and it gets loaded every time you
call load - even if it already is in memory.
Another difference between Kernel#require and Kernel#load is that Kernel#load takes an optional second argument that allows you to wrap the loaded code into an anonymous empty module.
Unfortunately, it's not very useful. First, it's easy for the loaded code to break out of the module, by just accessing the global namespace, i.e. they still can monkeypatch something like class ::String; def foo; end end. And second, load doesn't return the module it wraps the code into, so you basically have to fish it out of ObjectSpace::each_object(Module) by hand.
I was running a Rails application and in Gemfile, I had a specific custom gem I created with the option "require: false". Now when I loaded up rails server or rails console, I was able to require the gem in the initializer and the gem was loaded. However, when I ran a spec feature test with rspec and capybara, I got a load error. And I was completely bewildered why the Gem was not found in $LOAD_PATH when running a test.
So I reviewed all the different ways that load, require, rubygems and bundler interact. And these are a summary of my findings that helped me discover the solution to my particular problem:
load
1) You can pass it an absolute path to a ruby file and it will execute the code in that file.
load('/Users/myuser/foo.rb')
2) You can pass a relative path to load. If you are in same directory as file, it will find it:
> load('./foo.rb')
foo.rb loaded!
=> true
But if you try to load a file from different directory with load(), it will not find it with a relative path based on current working directory (e.g. ./):
> load('./foo.rb')
LoadError: cannot load such file -- foo.rb
3) As shown above, load always returns true (if the file could not be loaded it raises a LoadError).
4) Global variables, classes, constants and methods are all imported, but not local variables.
5) Calling load twice on the same file will execute the code in that file twice. If the specified file defines a constant, it will define that constant twice, which produces a warning.
6) $LOAD_PATH is an array of absolute paths. If you pass load just a file name, it will loop through $LOAD_PATH and search for the file in each directory.
> $LOAD_PATH.push("/Users/myuser")
> load('foo.rb')
foo.rb loaded!
=> true
require
1) Calling require on the same file twice will only execute it once. It’s also smart enough not to load the same file twice if you refer to it once with a relative path and once with an absolute path.
2) require returns true if the file was executed and false if it wasn’t.
3) require keeps track of which files have been loaded already in the global variable $LOADED_FEATURES.
4) You don’t need to include the file extension:
require 'foo'
5) require will look for foo.rb, but also dynamic library files, like foo.so, foo.o, or foo.dll. This is how you can call C code from ruby.
6) require does not check the current directory, since the current directory is by default not in $LOAD_PATH.
7) require_relative takes a path relative to the current file, not the working directory of the process.
Rubygems
1) Rubygems is a package manager designed to easily manage the installation of Ruby libraries called gems.
2) It packages its content as a zip file containing a bunch of ruby files and/or dynamic library files that can be imported by your code, along with some metadata.
3) Rubygems replaces the default require method with its own version. That version will look through your installed gems in addition to the directories in $LOAD_PATH. If Rubygems finds the file in your gems, it will add that gem to your $LOAD_PATH.
4) The gem install command figures out all of the dependencies of a gem and installs them. In fact, it installs all of a gem’s dependencies before it installs the gem itself.
Bundler
1) Bundler lets you specify all the gems your project needs, and optionally what versions of those gems. Then the bundle command installs all those gems and their dependencies.
2) You specify which gems you need in a file called Gemfile.
3) The bundle command also installs all the gems listed in Gemfile.lock at the specific versions listed.
4) Putting bundle exec before a command, e.g. bundle exec rspec, ensures that require will load the version of a gem specified in your Gemfile.lock.
Rails and Bundler
1) In config/boot.rb, require 'bundler/setup' is run. Bundler makes sure that Ruby can find all of the gems in the Gemfile (and all of their dependencies). require 'bundler/setup' will automatically discover your Gemfile, and make all of the gems in your Gemfile available to Ruby (in technical terms, it puts the gems “on the load path”). You can think of it as an adding some extra powers to require 'rubygems'.
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)
require 'bundler/setup' if File.exist?(ENV['BUNDLE_GEMFILE'])
2) Now that your code is available to Ruby, you can require the gems that you need. For instance, you can require 'sinatra'. If you have a lot of dependencies, you might want to say “require all of the gems in my Gemfile”. To do this, put the following code immediately following require 'bundler/setup':
Bundler.require(:default)
3) By default, calling Bundler.require will require each gem in your Gemfile. If the line in the Gemfile says gem 'foo', :require => false then it will make sure foo is installed, but it won’t call require. You’ll have to call require('foo') if you want to use the gem.
So given this breadth of knowledge, I returned to the issue of my test and realized I had to explicitly require the gem in rails_helper.rb, since Bundler.setup added it to $LOAD_PATH but require: false precluded Bundler.require from requiring it explicitly. And then the issue was resolved.
I started building Ruby bindings for the Marvel Comics API earlier this month. At the time, there was no gem named marvel on RubyGems, so I fired up jeweler, created a project, and began making a crude, but useable first release. I tested it by rake installing it locally and requiring it in a dummy project that let me play with it in pry:
require 'marvel'
require 'dotenv'
require 'pry'
Dotenv.load
#client = Marvel::Client.new
#client.configure do |config|
config.api_key = ENV['API_KEY']
config.private_key = ENV['PRIVATE_KEY']
end
binding.pry
When I got to the point where I had exposed several endpoints (at this commit) I attempted releasing it to rubygems.org, but discovered someone by then had released a marvel gem. I hastily altered my Rakefile and renamed mine to marvel_api and released it.
I let it sit for a few days before I came back and started experimenting with adding in Faraday middleware to try and clean it up. However, I never seem to have tested whether the name change to marvel_api worked. Now, whenever I try to require marvel_api, I'm met with this LoadError:
/Users/Raevynheart/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- marvel_api (LoadError)
from /Users/Raevynheart/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from test.rb:1:in `<main>'
I'm trying to understand if this is happening because my process for renaming the gem was incorrect, or if this is some separate issue. The gem's source is here: https://github.com/O-I/marvel. Note that the repo name and gem name are different — I don't know if that is an issue. Let me know if there is any other information I need to add to help troubleshoot this. Thanks for any help!
I think you are facing this issue since within your gem's lib directory, you still have the file named as marvel.rb.
From http://guides.rubygems.org/make-your-own-gem/ :
Code for your package is placed within the lib directory. The convention is to have one Ruby file with the same name as your gem, since that gets loaded when require 'hola' is run. That one file is in charge of setting up your gem’s code and API.
So, I believe your issue will resolve by changing your filename within lib to marvel_api.rb.
I am creating a gem where I'd like to define some constants to be available.
In my actual gemspec, I added the following:
config = File.expand_path('../config', __FILE__)
$LOAD_PATH.unshift(config) unless $LOAD_PATH.include?(config)
require 'constants.rb'
In constants.rb I have a simple var defined: $FOO = "Hello, World!"
Then in my lib/gem_name/core.rb, I'm attempting to puts $FOO but it doesn't seem to be available. No error, just comes up blank. Am I not understanding how gem dependencies and the require tree works here?
** UPDATE **
I have also tried just adding a config directory directly underneath lib which is in the LOAD_PATH already. then in my library, I am attempting to require config/constants, but that's saying it cannot load such a file.
I have also tried just moving constants.rb to the lib directory directly and requiring that, and it's warning me that it cannot load such file. Something is terribly wonky.
According to Katz,
When your gem is built, Rubygems will run that code and create a static representation. This means it’s fine to pull your gem’s version or other shared details out of your library itself. Do not, however, use other libraries or dependencies.
That means that require 'constants.rb' and $LOAD_PATH.unshift(...) etc are run when you build the gem. At runtime, it doesn't change the $LOAD_PATH or cause a global require. Use gem.require_paths instead to modify $LOAD_PATH at runtime.
For example, in your gemspec, use
gem.files += Dir['config/**/*']
gem.require_paths = %w[lib config]
Then in places where $FOO is required, use
require 'constants'
Side Notes
You don't need to include the .rb extension when using require.
Make sure all the files you need are in gem.files.
I've built a custom Ruby gem. Call it MyGem, then file lib/innermodule.rb contains:
module MyGem
module InnerModule
def self.foo(); puts "Hello world!"; end
end
end
To reference this from another gem that's in development I have to do:
require 'mygem'
require 'innermodule'
Is this normal behaviour, or is there a problem with the gemspec for MyGem?
I don't know if this is necessarily a problem with your gemspec since you usually just specify what files to include in a gem. Gemspecs don't really have anything to do with the way a gem gets required into another app.
It sounds like a problem with the way your gem is built/packaged specifically with regards to naming and file path conventions.
There are some common conventions that are usually followed for building gems and what I referenced above
http://guides.rubygems.org/patterns/ has a good overview.
Basically, you usually want to create a single file (usually the name of your gem) that sits in the "lib" directory. In this case, "lib/mygem.rb" would have individual requires for the internal dependencies of the gem.
#lib/mygem.rb
require 'innermodule'
Then to include the gem (as well as the inner module) in any other app, you could just do
require 'mygem'
I've got a custom gem that has been working just fine with regards to bundling, building, distributing, & implementing. The gem is the core of a framework from which other gems are derived. Since most derived gems will have the same basic structure, I want to include a Ruby script in the bin path of the gem that can be used to basically copy files from a template folder into a new folder where the user will develop their own gem.
The problem I'm having is that the template folder has a gemspec file named $name$.gemspec with similarly named classes/modules in the file (e.g.: module $Name$), where the $name$ gets replaced with a name provided by the user.
Unfortunately, when I run bundle install from my gem's top-most path, I get an error:
There was a SyntaxError while evaluating $name$.gemspec:
C:/my_gem/template/$name$.gemspec:8: syntax error, unexpected tGVAR
gem.version = MyGem::$Name$::VERSION
It looks like Bundler is using the wrong Gemfile, even if I explicitly pass the Gemfile or path via one of the following:
bundle install --gemfile=Gemfile
bundle install --path=C:\my_gem
I also tried updating the gemspec line of my Gemfile to no avail:
gemspec name: 'my_gem'
Lastly, I've ensured that the template folder isn't even included in my_gem.gemspec, but that doesn't seem to matter:
gem.files = Dir.glob("lib/**/*") + %w(LICENSE.txt README.md)
Does anyone know why Bundler is trying to read the ./template/$name$.gemspec instead of ./my_gem.gemspec?
Inspecting the Bundler source, I may have spotted the culprit in lib/bundler/source/path.rb. There's GLOB used to find gemspecs in load_spec_files. The default glob is "{,*,*/*}.gemspec". This will find *.gemspec in the root directory of your gem or any directory one descendant from root (which will include your template dir).
If this is indeed the culprit, you could work around this by placing your template directory deeper in your gem's dir hierarchy or changing the name of the template file so it doesn't end in .gemspec. The Bundler::Source::Pathobject looks like it can take a different glob at initilization but I haven't dug deep enough to see if there's a viable way to specify this alternative glob in bundle execution via config or cmdline options.