When I run the guard command it gives the following warning:
Guard here! It looks like your project has a Gemfile, yet you are
running guard outside of Bundler. If this is your intent, feel free
to ignore this message. Otherwise, consider using bundle exec guard
to ensure your dependencies are loaded correctly.
Is this hinting to me that Rails is not configured to work with Bundler correctly, or is it normal? It's not the expected behavior in the tutorial I'm following.
You should run bundle exec guard instead. Or, alternatively, run bundle install --binstubs, then you may run guard with bin/guard (it creates a script at this location). This is the recommended way of running all commands coming from gems installed with bundle install.
(If I understand it correctly) It ensures that you run the specific version of the gem specified in the bundle as well as that this gem will not be able to run gems which are installed on you computer but not included in the Gemfile (which could fool you into believing that you project is fine until you try to run it on a different computer, or a production server, where the other gem would be missing). It also does a lot of of stuff which, frankly, I have no idea about.
More info in the docs.
Related
For reasons to do with my CI setup I've needed to change the location where I install my Ruby gems from the default location to: bundle config set path 'vendor/bundle'
However, as soon as I do so, Sorbet loses it's cool and throws out over 6,000 errors. Why would Sorbet be so sensitively dependent on where the gem is installed? (I clear all of the gems before switching location so it's very unlikely to be due to a clash of gem versions).
Summary
When gems are installed to:
/Users/my-home-directory/.rbenv/versions/2.7.5/lib/ruby/gems/2.7.0/gems
bundle exec srb tc works fine. But when gems are installed to:
/Users/my-home-directory/project-name/vendor/bundle/ruby/2.7.0/gems/
then running bundle exec srb tc generates thousands of errors.
By default, Sorbet attempts to typecheck the entire directory under project-name. Try adding the following line to sorbet/config:
--ignore=/vendor/bundle
(This should be automatically included in newer installs of sorbet that incorporate https://github.com/sorbet/sorbet/pull/3897 )
Last version of https://github.com/serverspec/specinfra is broken (https://github.com/serverspec/specinfra/pull/229).
so when I execute:
kitchen verify
it doesn't verify and just throw some errors.
So I thought - How to specify some particular version of specinfra gem for test-kitchen?
then I could just specify previous version that worked and continue development.
I'm sure that this particular error will be fixed, but it would be great to know how to change versions of gems that test-kitchen uses.
Because it will happen again.
Unfortunately not super easily. The actual serverspec gem install is done on the target system via busser-serverspec. This code calls RubyGems directly, so it is hard to override. If I'm reading that #test hook correctly you may be able to include a Gemfile in your suite files that pulls in specinfra from git after the initial install.
I have some gems that are only used for the asset pipeline. One example is:
gem 'jquery-datatables-rails', github: 'rweng/jquery-datatables-rails'
Unfortunately, I can not find exactly where this gem is installed. "gem list --local" does not even show it.
I need to fix it, because I am trying to use Bootstrap styling in datatables, which is allowed in the latest version. But the version of datatables included with the gem is old.
Does anybody know where these gems go? I am very, very confused by the asset pipeline.
I such cases, I fork the project on github and make my changes, and adjust my Gemfiles accordingly. This also makes it reuseable in different projects.
The asset pipeline and Bundler grouping has nothing to do with where gems are installed on your system. You can always run bundle open gemname to open the source of a Gem in your $EDITOR and make quick changes (i.e. for debugging). If you want to actually include changes in a release, though, you are going to want to fork the Gem and make your changes there, then specify the git path in your Gemfile.
As a side note, make sure you run bundle install (or really, just bundle) after making changes to your Gemfile to ensure the Gems all get installed.
Do these things accomplish exactly the same?
starting a ruby process with bundle exec ruby foo.rb
having require "bundler/setup" as the first line of foo.rb
In your specific example they can be considered the same, however in reality they are not the same.
bundle exec makes some changes to the environment that bundler/setup does not make. If your foo.rb never runs a subshell, or never tries to run other ruby executables in subshells, then both versions are equivalent (they will both load bundled gems correctly and work exactly the same).
The whole idea with bundle exec is to enable you to run executables that were not originally designed with bundler in mind. Like rspec, rails, rackup. If your own app (foo.rb) does not try to run such executables that might be dependent on your bundles, then it makes no difference either way. Since all you want to make sure with bundler is that you load the correct gems, and for that bundler/setup works exactly as expected in your case.
From the bundler docs when talking about running ruby system executables:
In some cases, running executables without bundle exec may work, if the executable happens to be installed in your system and does not pull in any gems that conflict with your bundle.
However, this is unreliable and is the source of considerable pain. Even if it looks like it works, it may not work in the future or on another machine.
Then from the manpage of bundle exec you can get some additional clues as to what bundle exec actually does:
ENVIRONMENT MODIFICATIONS
make sure that it's still possible to shell out to bundle from inside a command invoked by bundle exec (using $BUNDLE_BIN_PATH)
put the directory containing executables (like rails, rspec, rackup) for your bundle on $PATH
make sure that if bundler is invoked in the subshell, it uses the same Gemfile (by setting BUNDLE_GEMFILE)
add -rbundler/setup to $RUBYOPT, which makes sure that Ruby programs invoked in the subshell can see the gems in the bundle
So if you build your app with bundler support in mind, then you never need to bundle exec your app.
But if you need to use other tools that load your app code that might load gems before they load your app code (which then might pull in a wrong non-bundled gem), then you need to use bundle exec.
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.