How can I get the default values that bundle uses for various unconfigured variables? If I try
bundle config get disable_shared_gems
You have not configured a value for `disable_shared_gems`
Yet I'm sure bundler has some idea of what to do about shared gems, since it keeps trying to install them even though I have versions obtained via apt install ruby-*
All I can see via bundle config get/list is the PATH variable, which I have set in ~/.bundle/config. If I don't set PATH, it uses my sudo capabilities without asking and "helpfully" installs to some system directories.
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 )
I come from a Python and JavaScript background.
When developing a JavaScript project, dependencies are installed in a node_modules directory in the project root.
When developing Python project, typically virtualenvwrapper is used. In this case dependencies are installed in a virtual environment, which is located in ~/.virtualenvs/<project_name> by default.
Now I need to use a ruby tool for a project. The tool that appears to be the most promising for a similar setup as described above, is bundler.
However, the default installation location for bundler is system-wide. I consider this to be harmful.
For one of my systems, it will prompt for a password, at which point I can still abort.
However, for my other system I can write into the global ruby installation. I'm using a homebrew installed ruby here. Bundle will just install dependencies globally.
I know I can specify the installation location by adding --path, but this is easy to forget.
One way to enforce an installation path is by committing .bundle/config. It would just have to contain this:
---
BUNDLE_PATH: "."
However, some googling around shows that it's not adviced to commit this file.
What is the recommended way to prevent accidental global installations using bundler?
Who's to say it will be accidental? It really depends on what context you're talking about here. I have my Ruby set up so that bundle install works without requiring sudo, it's all done through rbenv automatically. The same is true with rvm if done as a user-level install.
When it comes to deploying apps and you want to make sure it's deployed correctly, that's where tools like Capistrano come into play: Create a deployment script that will apply the correct procedure every time.
Checking in a .bundle/config is really rude from a dev perspective, just like checking in any other user-specific preferences you might have. It causes no end of conflict with other team members.
I'm developing on windows and use image_optim and the image_optim_pack gems. Previously, pushing these to Heroku was not a problem, everything resolved normally. Now I get a new warning and production fails:
Unable to use the platform-specific (x86_64-linux) version of image_optim_pack (0.5.0.20170609) because it has different dependencies from the ruby version.
To use the platform-specific version of the gem, run `bundle config specific_platform true` and install again.
remote: Could not find image_optim_pack-0.5.0.20170609 in any of the sources
I've tried to set a env var on heroku to allow this, but it seems like Heroku only allows to set vars for bundle install (e.g. --without), their article here doesn't help me:
https://devcenter.heroku.com/articles/bundler-configuration
Question: How can I set platform_specific to true on Heroku?
Problem solved. The correct way to add the variable is to write it like this:
In the KEY field:
BUNDLE_SPECIFIC_PLATFORM
In the VALUE field:
true
I noticed this after setting the local config for bundler and checking the text file on my machine.
I want to have a Ruby Gem that will have the same executable as another Gem.
When called with command args it will either do something, or pass the command on to the other Gem.
The first problem I have is that it isn't able to run two same named executables. I get this error:
Bundler is using a binstub that was created for a different gem. This is deprecated, in future versions you may need to bundle binstub yourgem to work around a system/bundle conflict.
How can I have Gems with the same named executables and ensure that the target one executes?
You cannot rely on Bundler or Rubygems to manage this for you. All it does it copy an executable that you specified in your gem spec to its bin/ directory.
The first problem you'll have is that the executable that runs may be dependent on the order in which the gems were installed which you can't guarantee.
Another problem that you'll have is that you cannot execute code on gem installation so you will be unable to run code that would try to automate this set up for people who install your gem.
I believe your gem should provide a non-conflicting executable. You can then supply post install instructions in your gem spec that are displayed to a user installing the gem, in the README, in a blog post, etc. you can tell the user that they need to set up an alias that points to your executable. In all shells that I'm aware of aliases will be executed before filesystem executables.
For the times when people want to bypass your alias and execute the original executable you can tell people to escape the command, e.g. \original-gem. That bypasses alias and function lookup in most shells and will allow users to have your super awesome version as the default (thru the alias) and a way to easily access the original.
I have a custom Ruby library directory that I'd like to have automatically added to Ruby's load path whenever Ruby is executed. I know I can use the -I option to Ruby, but is there something like an environment variable that I can set that will globally determine Ruby's load path.
I want to install Ruby Gems on a Linux box where I don't have root privileges, so I need to have a Ruby load path in a non-standard location. I installed RubyGems per "Installing RubyGems in a User Directory", but the gem command isn't picking up the non-standard load path.
Maybe I'm missing something obvious here and making things harder for myself?
See the "Ruby and Its World" chapter from The Pickaxe Book, specifically the section on environment variables. Excerpt:
RUBYLIB
Additional search path for Ruby programs ($SAFE must be 0).
DLN_LIBRARY_PATH
Search path for dynamically loaded modules.
RUBYLIB_PREFIX
(Windows only) Mangle the RUBYLIB search path by adding this
prefix to each component.
Make sure that you've placed the installed bin directory in your $PATH for the gem
command to work. It should modify the RUBYLIB itself, but if not, try Martin's answer to fix that.
Then, you can have your gem home (where the gems that rubygems installs are stored) be local.
Just use $GEM_HOME (or set things up in your ~/.gemrc) and check that everything took with gem environment.
% mkdir ~/.gems
% export GEM_HOME=~/.gems
% gem help environment
Usage: gem environment [arg] [options]
Common Options:
-h, --help Get help on this command
-V, --[no-]verbose Set the verbose level of output
-q, --quiet Silence commands
--config-file FILE Use this config file instead of default
--backtrace Show stack backtrace on errors
--debug Turn on Ruby debugging
Arguments:
packageversion display the package version
gemdir display the path where gems are installed
gempath display path used to search for gems
version display the gem format version
remotesources display the remote gem servers
display everything
Summary:
Display information about the RubyGems environment
Description:
The RubyGems environment can be controlled through command line arguments,
gemrc files, environment variables and built-in defaults.
Command line argument defaults and some RubyGems defaults can be set in
~/.gemrc file for individual users and a /etc/gemrc for all users. A gemrc
is a YAML file with the following YAML keys:
:sources: A YAML array of remote gem repositories to install gems from
:verbose: Verbosity of the gem command. false, true, and :really are the
levels
:update_sources: Enable/disable automatic updating of repository metadata
:backtrace: Print backtrace when RubyGems encounters an error
:bulk_threshold: Switch to a bulk update when this many sources are out of
date (legacy setting)
:gempath: The paths in which to look for gems
gem_command: A string containing arguments for the specified gem command
Example:
:verbose: false
install: --no-wrappers
update: --no-wrappers
RubyGems' default local repository can be overriden with the GEM_PATH and
GEM_HOME environment variables. GEM_HOME sets the default repository to
install into. GEM_PATH allows multiple local repositories to be searched
for
gems.
If you are behind a proxy server, RubyGems uses the HTTP_PROXY,
HTTP_PROXY_USER and HTTP_PROXY_PASS environment variables to discover the
proxy server.
If you are packaging RubyGems all of RubyGems' defaults are in
lib/rubygems/defaults.rb. You may override these in
lib/rubygems/defaults/operating_system.rb
Make life easy and install RVM. It will install whatever version of Ruby you want and let you switch between them and it doesn't require root access. It has many other killer features you will become addicted to after using it for a while.
I used #MartinCarpenter's solution to run a specific/particular/single test method with minitest. Where I normally add the test directory to the $LOAD_PATH with Rake::TestTask, e.g., t.libs << 'test', I was able to do it with the command line, like so:
RUBYLIB=test ruby test/user_test.rb --name test_create
I added test to $LOAD_PATH because user_test.rb calls require 'test_helper' to load lib/test_helper.rb.