The Gem Development guide says that the Gemfile.lock file "should always be checked into version control." However, this is NOT true for Gems. For Applications, like your Rails apps, Sinatra apps, etc., it is true. The same does not go for Gems.
For clarification, please see Yehuda's guidance on the roles of .gemspec, Gemfile, and Gemfile.lock files: Clarifying the roles of .gemspec and Gemfile
I don't understand his reason. What if my gem depends on say Rails 3 and is not compatible with Rails 4? Don't I need to then commit my Gemfile.lock which specifies that my gem is only compatible with Rails 3?
This article is a bit dated (~6 years old) although it holds merit in the fact that the gemspec will hold the version controlling. If your gem has a dependency on a specific rails version you would add:
s.add_dependency "rails", "3.2"
When a user tries to use your gem on rails > 3.2 the dependency kicks in.
Hope that answers your question. If not, please clarify and I will update this post.
Related
I have a gem that I one of the owner/authors (hyperloop) that depends on another gem (opal-rails) which depends on another gem (opal-jquery).
All gems depend on the gem opal. The problem is the current released version of opal-query is locked to an older version of the opal gem.
The version of opal-jquery on master is okay. For whatever reason the author(s) have not pushed ruby gems, so I have to work around this.
The work around is that I have to say
gem 'hyperloop'
gem "opal-jquery", git: "https://github.com/opal/opal-jquery.git", branch: "master"
in the application Gemfile.
I am hoping somebody can give a workaround that could be embedded in the hyperloop gemspec, so that the problem is taken care of there.
I thought if I added
gem "opal-jquery", git: "https://github.com/opal/opal-jquery.git", branch: "master"
to the hyperloop Gemfile this would take care of it, but apparently not.
There isn't really a way to manage the dependencies of your dependencies. You have 2 options here:
1) Use an older version of opal
2) Clone the opal-jquery gem and modify its Gemfile, pointing to the version of opal you want it to use, then, in your Gemfile, point the opal-jquery gem to pull from your cloned version of the repo
Neither of these is really ideal and you'd have issues if you ever decided to upgrade to a newer version of opal-jquery if you go with the second route
I'm pretty new to Ruby and have been reading up about Gemfiles and the like. Recently we were bitten by this bug in one of our programs:
https://github.com/ffi/ffi/issues/440
However, in looking through the Gemfile in question, the ffi gem wasn't listed. It is now, pinned to a prior (working) version for the OS in question.
But I'm wondering how things worked before if it wasn't in the Gemfile to start? Are there some 'core' gems out there that come along for the ride, with no need to put them in a Gemfile?
Gems have dependencies and so they get installed as well. You can check your Gemfile.lock to see exactly which gems are installed.
Is there a way to use an earlier version of RSpec without uninstalling the default version? If not, what's the safest way to replace the current version? The uninstall/reinstall instructions linked to in this SO answer seem to be gone.
I'm trying to learn testing with RSpec, and all the tutorials I've found seem to predate 3.0. I invariably get deprecation warnings (if I'm lucky) or errors when using their old expectation syntax. I've relied heavily on this article to set me straight, but the time I spend updating the syntax in the tutorials' examples keeps me from concentrating on the substance of the lessons.
The same SO answer I linked to mentioned a config option in Rails' environment.rb file, but I'm not using Rails for the current tutorial, just Ruby and (eventually) Sinatra. I'm wondering if I can just add that file to be project folder.
I did add a Gemfile with the RSpec 2.1:
source 'https://rubygems.org'
gem 'rspec', '~> 2.10.0'
gem 'guard'
gem 'guard-rspec'
gem 'terminal-notifier'
gem 'terminal-notifier-guard'
The 2.1 installed after running bundle install, but after running bundle exec init and running my specs with the old syntax, I still get the same deprecation warnings and errors.
I'm writing a new gem I'm basing off of Yehuda's new gem template and I'm slightly confused. Having a Gemfile with dependencies, and also specifying a gemspec with dependencies seems redundant to me. Can someone explain why this is desirable and if it's truly necessary?
Note, this is the first gem I've ever written so I'm new to all of this.
The .gemspec dependencies tell rubygems what it needs to grab to resolve the dependencies when a user installs your gem. The Gemfile is to manage the dependencies while you develop the gem. Rubygems and Bundler aren't connected, at least not yet.
The gemspec is required to build the gem. The Gemfile is more of a convenience, so that people who are working on your gem can easily pull in all the dependencies via Bundler. In the case that you're developing multiple related gems at once, you may also want to put git sources in the Gemfile, so all of the HEAD versions can be tested against.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'd like to write a package for Ruby and make it available as a gem.
What are the tools, steps and pitfalls ?
Are there any good tutorials, screencasts, etc., which helped you learning how to do it ?
Rubygems.org's Guides is one of the best resources for writing your own gem.
If you're using Bundler in your app, you might want to look at Ryan Bigg's guide to Developing a RubyGem using Bundler and the Railscast on creating gems with Bundler.
If you're interested in tools to help you write gems:
Jeweler - Opinionated tool for creating and managing Rubygem projects. There's also a Gemcutter and Jeweler Railscast.
Hoe - From the guys at seattlrb.
gem-this adds a bunch of helpful rake tasks.
Some tutorials/guides:
Creating Your First Gem
Using bundler and rvm to build a rubygem - Using bundler and rvm to create a gem
Gem Packaging: Best Practices
Ruby Gem Recipe - Intro guide to creating a gem using bundler and jeweler
How to build a ruby gem and host it on gemcutter - tutorial using echoe and gemcutter
The Truth About Gemspecs - goes over gemspecs and tips for dealing with them
Packaging with RubyGems - a quickstart guide for Jeweler
gem that - James Adam - reviews tools that help build gems (hoe, newgem, echoe, gemhub, jeweler, gem this)
Using Gemcutter's Api from the Commandline
New Gem with Bundler – Sample Rakefile - Useful rakefile for deploying and publishing a gem
Let's Write a Gem
How To Build A Ruby Gem With Bundler, Test-Driven Development, Travis CI And Coveralls, Oh My!
This is how I usually create and release Gems:
Sign-up for https://github.com
Sign-up for https://rubygems.org
$ gem install ore rubygems-tasks rdoc rspec
$ mine awesome_gem
cd awesome_gem/ and edit the README.rdoc and awesome_gem.gemspec, write code in lib/awesome_gem/ and adding RSpec tests in specs/.
when you're ready to release, update the ChangeLog.rdoc file, run rake spec and rake rerdoc, open up html/index.html and double-check for any typos.
rake release
(Optional) submit a link and explanation of your new awesome gem to http://rubyflow.com
Sit back and bask in the glory of your first Gem. :)
You need not start writing a gem, just write some code, write some tests, use it however you want, and once you are happy with it, use gem this to generate the relevant Rakefile.
It helps if you stick to the approaches other gems take (have a lib directory, avoid naming files in ways that could clash with other gems, write some tests if you can, have a readme), but it's not necessary.
Once you have something you want to share, put it on github and push it to gemcutter.
Don't over think it, don't use hoe or other overkill tools, have fun, don't to anything I wouldn't do.