Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

Respect XDG basedir spec for global configuration file #4333

Closed
jasonkarns opened this issue Mar 4, 2016 · 8 comments
Closed

Respect XDG basedir spec for global configuration file #4333

jasonkarns opened this issue Mar 4, 2016 · 8 comments
Labels
type: feature-request

Comments

@jasonkarns
Copy link
Contributor

To conform to the XDG basedir spec, bundler's config file ought to be stored at ${XDG_CONFIG_HOME:-$HOME/.config}/bundler/config

I'm not completely sure what other files are stored under ~/.bundle, but there are other XDG-defined directories for cache and runtime files, if so needed.

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
@jasonkarns jasonkarns mentioned this issue Mar 4, 2016
Closed
@segiddins
Copy link
Member

a) that's a breaking change
b) dumb question but what does XDG stand for, and what makes it the authoritative spec for how command line apps store things on disk?

@jasonkarns
Copy link
Contributor Author

doesn't need to be a breaking change. most tools that have migrated do so by first checking if ~/.my-app exists and using it if so. If it doesn't exist, then the XDG settings are honored. This way people can opt-in by moving the files themselves (or removing the old ones). Some tools go a step further and migrate the files automatically.

XDG is a group that works on interoperability between *nix systems. The basedir spec is just one aspect of the larger focus of the group. The primary benefit to users is: standardized configurability by users/sysadmins across apps. (And it falls in lines with Apple guidelines on not polluting userspace)

git is the largest project that I'm aware of that conforms. keybase does as well. I've seen many others but can't recall them offhand.

@gioele
Copy link

gioele commented May 14, 2016

The problem is not limited to the configuration file, but also cache files.

Cache files should be stored at

${$XDG_CACHE_HOME:-$HOME/.cache}/bundler

instead of ~/.bundler/cache.

If we need to appeal to authority, we can add Firefox, Thunderbird, Chromium and Inkscape to the list of apps that follow the XDG Basedir spec and do not clutter our lovely $HOMEs. :)

@coilysiren
Copy link
Contributor

Doesn't seem like anyone on the team is too excited about implementing this, @jasonkarns or @gioele would you want to work on a PR? (we aren't guaranteed to merge it, but it would help make your case)

@valeth
Copy link

valeth commented Feb 15, 2017

Is anybody already working on this?

@segiddins
Copy link
Member

@valeth not at the moment!

@jasonkarns
Copy link
Contributor Author

jasonkarns commented Jun 5, 2017 via email

@valeth valeth mentioned this issue Jun 18, 2017
Closed
@gwerbin gwerbin mentioned this issue Sep 11, 2017
Merged
bundlerbot added a commit that referenced this issue Sep 18, 2017
@bundlerbot
Auto merge of #6024 - gwerbin:custom-user-bundle-dir, r=colby-swandale
e6cc7a2 
Allow user to override ~/.bundle with environment variables

### What was the end-user problem that led to this PR?

As in #4333, users wanted a way to make Bundler respect the XDG specification.

### What was your diagnosis of the problem?

The directory `~/.bundle` was hard-coded and could not be configured.

### What is your fix for the problem, implemented in this PR?

Allow users to configure `~/.bundle` and its relevant sub-directories by setting environment variables. The environment variables and their fallbacks are as follows:

| variable | fallback if unset |
|---|---|
| `BUNDLE_USER_HOME` | `$HOME/.bundle` |
| `BUNDLE_USER_CACHE`  | `$BUNDLE_USER_HOME/cache` |
| `BUNDLE_USER_CONFIG` | `$BUNDLE_USER_HOME/config` |
| `BUNDLE_USER_PLUGIN` | `$BUNDLE_USER_HOME/plugin` |

### Why did you choose this fix out of the possible options?

Unlike #5787, This solution is not specific to the XDG specification. Users have all kinds of setups, and this is a very general system for allowing them to configure their development machines however they need. It tries to keep all files created by Bundler in the same place (as per #5787 (comment)), but allows the user to override that convention _if they really want to and they know what they are doing_.

If they want to use XDG for everything, they can do it by explicitly setting the `BUNDLE_USER_*` variables to the equivalent `XDG_DATA_*`. If they just want to get `.bundle` out of their home directory, they can do it by setting `BUNDLE_USER_HOME` and don't have to mess with the more specific env variables if they don't want to.

To me, this solution strikes the right balance between "fine-grained control for power users" and "simple, sane defaults for everyone else".

Please let me know if my tests can be improved. My only Ruby experience so far has been writing Homebrew formulas and configuring Jekyll, so I'm sure I have a lot to learn.
@colby-swandale
Copy link
Member

This has been added in #6024

colby-swandale pushed a commit that referenced this issue Oct 9, 2018
@bundlerbot @colby-swandale
Auto merge of #6024 - gwerbin:custom-user-bundle-dir, r=colby-swandale
aad374a 
Allow user to override ~/.bundle with environment variables

### What was the end-user problem that led to this PR?

As in #4333, users wanted a way to make Bundler respect the XDG specification.

### What was your diagnosis of the problem?

The directory `~/.bundle` was hard-coded and could not be configured.

### What is your fix for the problem, implemented in this PR?

Allow users to configure `~/.bundle` and its relevant sub-directories by setting environment variables. The environment variables and their fallbacks are as follows:

| variable | fallback if unset |
|---|---|
| `BUNDLE_USER_HOME` | `$HOME/.bundle` |
| `BUNDLE_USER_CACHE`  | `$BUNDLE_USER_HOME/cache` |
| `BUNDLE_USER_CONFIG` | `$BUNDLE_USER_HOME/config` |
| `BUNDLE_USER_PLUGIN` | `$BUNDLE_USER_HOME/plugin` |

### Why did you choose this fix out of the possible options?

Unlike #5787, This solution is not specific to the XDG specification. Users have all kinds of setups, and this is a very general system for allowing them to configure their development machines however they need. It tries to keep all files created by Bundler in the same place (as per #5787 (comment)), but allows the user to override that convention _if they really want to and they know what they are doing_.

If they want to use XDG for everything, they can do it by explicitly setting the `BUNDLE_USER_*` variables to the equivalent `XDG_DATA_*`. If they just want to get `.bundle` out of their home directory, they can do it by setting `BUNDLE_USER_HOME` and don't have to mess with the more specific env variables if they don't want to.

To me, this solution strikes the right balance between "fine-grained control for power users" and "simple, sane defaults for everyone else".

Please let me know if my tests can be improved. My only Ruby experience so far has been writing Homebrew formulas and configuring Jekyll, so I'm sure I have a lot to learn.

(cherry picked from commit e6cc7a2)
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Dec 17, 2018
misc/ruby-bundler: update to 1.17.2
5aeff10 
pkgsr change
* Remove @Prefix@ from ALTERNATIVES file.

## 1.17.2 (2018-12-11)

 - Add compatability for bundler merge with Ruby 2.6

## 1.17.1 (2018-10-25)

 - Convert `Pathname`s to `String`s before sorting them, fixing #6760 and #6758 ([#6761](rubygems/bundler#6761), @alexggordon)

## 1.17.0 (2018-10-25)

No new changes.

## 1.17.0.pre.2 (2018-10-13)

Features:

  - Configure Bundler home, cache, config and plugin directories with `BUNDLE_USER_HOME`, `BUNDLE_USER_CACHE`, `BUNDLE_USER_CONFIG` and `BUNDLE_USER_PLUGIN` env vars ([#4333](rubygems/bundler#4333), @gwerbin)
  - Add `--all` option to `bundle binstubs` that will generate an executable file for all gems with commands in the bundle
  - Add `bundle remove` command to remove gems from the Gemfile via the CLI
  - Improve checking file permissions and asking for `sudo` in Bundler when it doesn't need to
  - Add error message to `bundle add` to check adding duplicate gems to the Gemfile
  - When asking for `sudo`, Bundler will show a list of folders/files that require elevated permissions to write to.

The following new features are available but are not enabled by default. These are intended to be tested by users for the upcoming release of Bundler 2.

  - Improve deprecation warning message for `bundle show` command
  - Improve deprecation warning message for the `--force` option in `bundle install`

## 1.17.0.pre.1 (2018-09-24)

Features:

  - Check folder/file permissions of the Bundle home directory in the `bundle doctor` command ([#5786](rubygems/bundler#5786), @ajwann)
  - Remove compiled gem extensions when running `bundle clean` ([#5596](rubygems/bundler#5596), @akhramov)
  - Add `--paths` option to `bundle list` command ([#6172](rubygems/bundler#6172), @colby-swandale)
  - Add base error class to gems generated from `bundle gem` ([#6260](rubygems/bundler#6260), @christhekeele)
  - Correctly re-install gem extensions with a git source when running `bundle pristine` ([#6294](rubygems/bundler#6294), @wagenet)
  - Add config option to disable platform warnings ([#6124](rubygems/bundler#6124), @agrim123)
  - Add `--skip-install` option to `bundle add` command to add gems to the Gemfile without installation ([#6511](rubygems/bundler#6511), @agrim123)
  - Add `--only-explicit` option to `bundle outdated` to list only outdated gems in the Gemfile ([#5366](rubygems/bundler#5366), @peret)
  - Support adding multiple gems to the Gemfile with `bundle add` ([#6543](rubygems/bundler#6543), @agrim123)
  - Make registered plugin events easier to manage in the Plugin API (@jules2689)
  - Add new gem install hooks to the Plugin API (@jules2689)
  - Add `--optimistic` and `--strict` options to `bundle add` ([#6553](https://github.com/bundler/bundler/issues/6553), @agrim123)
  - Add `--without-group` and `--only-group` options to `bundle list` ([#6564](rubygems/bundler#6564), @agrim123)
  - Add `--gemfile` option to the `bundle exec` command ([#5924](rubygems/bundler#5924), @ankitkataria)

The following new features are available but are not enabled by default. These are intended to be tested by users for the upcoming release of Bundler 2.

  - Make `install --path` relative to the current working directory ([#2048](rubygems/bundler#2048), @igorbozato)
  - Auto-configure job count ([#5808](rubygems/bundler#5808), @segiddins)
  - Use the Gem Version Promoter for major gem updates ([#5993](rubygems/bundler#5993), @segiddins)
  - Add config option to add the Ruby scope to `bundle config path` when configured globally (@segiddins)

## 1.16.6 (2018-10-05)

Changes:

  - Add an error message when adding a gem with `bundle add` that's already in the bundle ([#6341](rubygems/bundler#6341), @agrim123)
  - Add Homepage, Source Code and Chanagelog URI metadata fields to the `bundle gem` gemspec template (@walf443)

Bugfixes:

  - Fix issue where updating a gem resulted in the gem's version being downgraded when `BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS` was set ([#6529](rubygems/bundler#6529), @theflow)
  - Fix some rescue calls that don't specifiy error type (@utilum)
  - Fix an issue when the Lockfile would contain platform-specific gems that it didn't need ([#6491](rubygems/bundler#6491), @segiddins)
  - Improve handlding of adding new gems with only a single group to the Gemfile in `bundle add` (@agrim123)
  - Refactor check for OpenSSL in `bundle env` (@voxik)
  - Remove an unnecessary assignment in Metadata (@voxik)

Documentation:

  - Update docs to reflect revised guidance to check in Gemfile.lock into version control for gems ([#5879](https://github.com/bundler/bundler/issues/5879), @arbonap)
  - Add documentation for the `--all` flag in `bundle update` (@agrim123)
  - Update README to use `bundle add` in usage examples (@hdf1986)
@machupicchubeta machupicchubeta mentioned this issue Oct 29, 2023
Merged
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
type: feature-request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@jasonkarns @gioele @colby-swandale @segiddins @valeth @coilysiren