Ok, as #tim-moore asked, I will post it in new question.
Ok, so I wanted to make gem using bundle. Pry extension gem require that gem start with pry- as mentioned here.
I used:
bundle gem pry-name
but it messed up my file structure
create pry-name/pry-name.gemspec
create pry-name/lib/pry/name.rb
create pry-name/lib/pry/name/version.rb
As you can see it created lib/pry directory. I know it's gem's style to created such structure but now I pry cannot load this gem automatically
One solution from my question was:
create pry-name.rb that contain only require 'pry/name'
After I have done this, and build gem, I started pry:
This message appear:
require 'pry-name' # Failed, saying: Pry is not a module
As for my guesses:
I'm creating commands writing something like this:
Pry::Commands.create_command "name-of-command" do
# my code goes here
end
and, as ruby find Pry::Commands. it want require it from lib directory not from Pry gem.
What does this error mean. Why it doesn't work. How make it work keeping in mind gem and pry requirements(pry gem starts with pry- and gem will create another directory(ies) when someone use - for example: gem pry-name will make pry/name)
Everywhere in your newly-created gem where it has module Pry, change it to: class Pry. Since Pry is already defined (as a class), you cannot redefine/reopen it as a module.
Related
I noticed for some gems you must include it in the file where you want to use it like this require 'a_gem', but this is not always the case.
I am going to compose a gem by myself. What should I do if I do not want to add the require 'my_gem' to the .rb file when using it?
Usually, an application that is using a gem needs to require the gem:
require "my_awesome_gem"
MyAwesomeGem.do_something_great
However, if an application is using bundler, which defines the application's gem in a file called "Gemfile":
source 'http://rubygems.org'
gem 'my_awesome_gem'
then the application may invoke bundler in a way that automatically requires all of the gems specified in the Gemfile:
require "bundler"
Bundler.require
MyAwesomeGem.do_something_great
Rails projects use Bundler.require, so a Rails application will not need to explicitly require a gem in order to use it: Just add the gem to the Gemfile and go.
For more about Bundler.require, see the bundler documentation
For more about how Rails uses Bundler, see How Does Rails Handle Gems? by Justin Weiss.
This doesn't make sense. If you want to write a Gem and use it, it needs to be required somewhere.
This "somewhere" could be explicit in one of your scripts, it could be written in a Gemfile or it could be required by another script/gem that is required by your script.
If you write a gem, Ruby will not include it automatically in all your scripts.
Finally, if you publish it, should every single Ruby script on earth magically require it and execute your code?
I suppose that the project you have seen which didn't use require 'a_gem' was using a Gemfile.
I forked a gem I use a lot in order to code some enhancements on it. I want it to be installed in a subfolder called ~/codebase/ruby, where I keep all my Ruby projects, arranged in subdirectories.
To do that, I built and installed the gem with the following commands:
gem build my_gem.gemspec
gem install mygem-x.x.gem -i./mygem
mygem is installed in ~/codebase/ruby/mygem. I can't get my client code (which is in another directory) to grab mygem from there.
I've tried all of the following without success:
Running ruby with argument -I<path_to_mygem>.
Adding <path_to_mygem> to PATH.
Putting :gempath: <path_to_mygem> into ~/.gemrc.
I know I could put the gem in ~/.gem/ruby/<version> (since it appears in gem env) and that would probably work, but that would break my existing directory structure of Ruby code, forcing me to code in a different directory only for mygem, which is something I want to avoid unless it's the only option.
Thoughts?
Hopefully you are using Bundler to load the required gems. Then you just specify the path to the gem file in your Gemfile:
gem 'my_gem', :path => '~/codebase/ruby/mygem'
When creating a gem, in the spec_helper, you are supposed to require the name of your gemfile, such as this:
require 'dogeify'
As explained here: Building a gem from scratch
My question is, what are you actually requiring? I don't see a file within the spec folder called dogeify.
The dogeify mentioned in the project is the lib/dogify.rb. When running rspec as such
bundle exec rake spec, from the root of the gem,
rspec will automatically add the lib directory to the load path and the helper_spec loads said file.
When you install a Gem, gemfile will be save to your ruby environment, and use require 'dogeify', then require function will find this file in ruby library folder or you application library, then load the module or class or function that defind by dogeify to your project. Offical explanation at this
I have a gem called "something".
I would like to add pry as a development dependency when developing the gem. However I don't know how to load it.
If I have "require something" inside lib/something.rb , when I release the gem, it throws a LoadError, because pry is only a development dependency.
At the same time I don't want to keep adding and removing pry when I am committing code.
What is the best way to require pry only when developing the application, but not require it as a dependency for the gem?
You can use the add_development_dependency in the gemspec file. You'll still have to require it in your lib/something.rb file within a begin .. rescue LoadError block. (Edit 2, see below)
In your case, it will be something like the following:
spec.add_development_dependency 'pry', '~> 0.9.12.2'
The purpose of add_development_dependency is to separate the gems into dependencies that get installed when you execute gem install mygem vs development-only dependencies that are installed only when you execute gem install mygem --development.
Edit: #Pierre-Louis Gottfrois' solution
Modify the Gemfile directly and add a test group. This question describes the process. This does not appear to be a preferred solution according to Yehuda Katz.
Edit 2: begin require ... rescue LoadError is apparently a common practice for Ruby scripts, according to this Making Ruby Gems article.
I think I found a workaround for that.
If you configure bundler to use pry as your console with
$ bundle config console pry
Then pry is itself required and you don't need to explicitly require in your source files.
Plus, you get a history on pressing ' ↑ '.
When using bundler with a project in general and Rails specifically, you have access only to gems defined in your Gemfile. While this makes sense, it can be limiting. Mostly I find it limiting when I want to use a certain RSpec formatter that the rest of the team doesn't use. Unless it's in the Gemfile, it isn't accessible.
Any way around it or I have to add it to Gemfile?
Update: my problem wasn't Bundler but Spork. When running RSpec without Spork I had no problem of using whatever formatter I wanted.
Update #2: it looks like that using Bundler is still the cause of the problem. The difference between using Spork and not using Spork, is that when running RSpec without Spork, it loads the formatter before loading your project and getting into the Bundler "sandbox".
With Bundler:
$ bundle exec irb
>> require 'fivemat'
LoadError: cannot load such file -- fivemat
from (irb):1:in `require'
from (irb):1
from /Users/arikfr/.rvm/rubies/ruby-1.9.3-p194/bin/irb:16:in `<main>'
Without Bundler:
$ irb
>> require 'fivemat'
=> true
In ChiliProject we allow users to create a Gemfile.local which is included into the main Gemfile on load. This allows users to specify additional gems without having to change our Gemfile to ease updates.
For that, we have included the following code at the bottom of our Gemfile.
gemfile_local = File.expand_path('Gemfile.local', __dir__)
if File.readable?(gemfile_local)
puts "Loading #{gemfile_local}..." if $DEBUG
instance_eval(File.read(gemfile_local))
end
The Gemfile.local itself is excluded from the repository via .gitignore.
I assume that none of these answers have been chosen as correct because they don't do a great job of solving the problem: having additional gems that you can use that by default don't require any changes to files already in the repository to achieve. That is, you don't have to modify any files, and you don't have to live with remembering not to check in your local changes. Here's how I do it.
The idea is basically inverting the dependencies of Holger's answer, such that there's no need to modify the shared Gemfile. Bundler allows one to specify which file is to be used as the gemfile, but strangely the documented methods do not apparently work with its configuration file and will not be fixed. There is a somewhat obscured feature of Bundler that any of the configuration options can be set in an environment variable or passed on the command line. Running all of your commands as bundle [command] --gemfile [yourgemfile] or BUNDLE_GEMFILE="[yourgemfile]" bundle [command] will cause Bundler to read whatever gemfile you want it to. I highly recommend using the environment variable approach, and either creating an alias or exporting the variable for your current session, particularly as I was unable to use the command line switch with the "exec" command.
Therefore, I run rspec like this: BUNDLE_GEMFILE="[mygemfile]" bundle exec rspec [filename], and I have the first part of this aliased as bem in my bashrc. Works like a charm.
Then, you should setup your source control to ignore your Gemfile, either in the project's .gitignore or, to keep the project entirely hygienic without changing even its .gitignore, to your personal global ignore file (which is by default in ~/.config/git/ignore and has the same format as a project's gitignore file).
One other thing to note is that Bundler will create a lockfile based on the Gemfile's name. This is super handy, as it keeps you from overwriting your project's Gemfile.lock if it's checked in, but you need to ignore this new lock file as well. If your gemfile is Foo.bar, look for Foo.bar.lock.
Finally, you can do something similar to Holger's suggestion in your custom Gemfile:
source "http://rubygems.org"
gem "fivemat"
instance_eval(File.read(File.dirname(__FILE__) + "/Gemfile"))
and you're good to go, as long as you remember to specify your Gemfile.
You can use something like this in your Gemfile:
gem 'foo' if ENV['ENABLE_FOO_GEM']
Then just set ENABLE_FOO_GEM in your environment.
export ENABLE_FOO_GEM=1
The gem will be disabled by default, but easily turned on (permanently) by anyone who wants to use it.
Add to .gitignore
Gemfile.local
Gemfile.local.lock
Add to the project a Gemfile.local.sample file with the following content:
# Include gems that are note meant to be part of the project but for development purposes
# That's why Gemfile.local and Gemfile.local.lock must be git-ignored
# To use these gems:
# 1. Create a "Gemfile.local" file (at same level of "Gemfile")
# 2. Prepend "BUNDLE_GEMFILE=Gemfile.local" before "bundle install" or "bundle exec rails c" and so forth.
eval_gemfile "./Gemfile"
group :development, :test do
# Suggested gems
gem "awesome_print", require:"ap"
gem "hirb"
gem "pry"
gem "pry-byebug"
gem "pry-rails"
gem "meta_request"
# My gems
gem "fivemat"
end
I believe the gem Devpack provides the functionality you are looking for.
The gem allows you to add a single gem to your Gemfile which will permit any developer to configure their own preferred set of development gems either for an individual project or globally by creating a .devpack file containing a list of gems.
(I am the author of this gem; I came across this post while developing it so thought it may be worth adding).
In case you still decide to do this (horrible idea):
You can add ruby code to your Gemfile to load a ~/.gemfile (or such) if it exists.
Something like:
eval(IO.read('~/.gemfile'), binding) if FileTest.exists?("~/.gemfile")