Arcanist should use the XDG config dir by default on Unix

At the moment, arcanist always checks for a config file in $HOME exclusively. Ideally, it should use $XDG_CONFIG_HOME/arcrc (if that env var exists), followed by $HOME/.config/arcrc as a backup. This behavior would be compliant with the XDG Base Directory Specification, as seen here.

As it’s been using ~/.arcrc for a while, I believe the best solution would be to check if ~/.arcrc already exists, and if it does, use it. Otherwise, use the above logic for determining which config location to use. This is the solution that Mozilla arrived at for NSS, and it’s backwards-compatible with existing installations.

I’ve already created a patch that follows this behavior, and can provide it on request (or you can find the commit on my arcanist fork at https://github.com/serebit/arcanist).

Why should XDG Base Directory Specification compliance be a goal of Arcanist?

Thanks for the reply.

Besides the obvious benefit to the end user of not having an additional file cluttering up $HOME, it’s a specification that’s meant to be followed by Unix applications, including Arcanist. In fact, the majority of Unix applications now support placement of config files in the .config directory, data in the .local/share directory, and cache in the .cache directory (as appropriate for the spec). Most applications that don’t follow the spec do so because other software expects their files to be in $HOME (OpenSSH, for example).

To me, it’s sort of like trying to justify why applications should use a single dash for single-letter options and two dashes for full-length options. The vast majority of Unix applications do this, and users expect this to be the case when they use a new application. The same goes for the XDG directories—when I install a new application, I expect it to store data in the directories that are for data storage, not in my home directory.

Even tools such as Git support XDG config directories. If ~/.config/git/config exists, it will use that file for the global git configuration rather than the usual ~/.gitconfig.

As such, I don’t think it unreasonable to suggest that Arcanist should follow this spec. As I’ve showed with my patch, it only takes a few lines of code to follow the spec in a backwards-compatible manner.

Compliance for the sake of compliance is not a goal of Arcanist, and Phabricator intentionally deviates from specifications in many cases when essentially any other goal is served.

Implementing behavior just because Git or Mercurial or GitHub or any other software package implements that behavior is also not a goal of Arcanist or Phabricator.

Here, the goal of a simpler implementation is clearly served without this patch.

See also:

https://secure.phabricator.com/T9770
https://secure.phabricator.com/book/phabricator/article/exit_codes/
https://secure.phabricator.com/T7650
https://secure.phabricator.com/T5155
https://secure.phabricator.com/D10176
https://secure.phabricator.com/T6012
https://secure.phabricator.com/T13153

Do you see there being any chance of Arcanist supporting this spec? Are you open to implementing support for it? You sound conclusive, but also haven’t outright said no yet, so I’d just like to make sure before I write any more paragraphs :stuck_out_tongue:

Arcanist may become compliant in the future if there is some real-world problem which compliance is the best solution to. There’s nothing fundamentally objectionable about the proposed behavior, it just increases complexity without being motivated by solving a specific problem that impacts actual users.

Well, if I may be candid, the reason I (and most others) go around creating issues for XDG basedir compliance is because we don’t like having files in our home directory that don’t need to be there. I know this is a shallow concern, but you’d be surprised how many people are bothered by this. It’s a similar situation on Windows—applications putting folders in the user directory or Documents is largely frowned upon, as they should be using APPDATA (which Arcanist does).

There is an entire Arch wiki page dedicated to applications that don’t comply to the spec by default, which offers solutions to resolve the problem for some of them. Most of these applications already have issues on their bug trackers for spec support. For many noncompliant applications, this can be solved by setting an environment variable that specifies where data should be stored, but Arcanist has no such environment variable that can be set. This means that, if I wish to use Arcanist, I am required to keep an additional file in my home directory.

It’s clear that you don’t want additional code complexity. I definitely understand this, but I am of the opinion that a few extra lines of code is justifiable for this purpose. In addition, this doesn’t need to be a permanent change, in that Arcanist doesn’t need to continue supporting ~/.arcrc forever if this patch is applied. The extra behavior is purely to continue supporting existing configurations, and can be omitted if desired. After some time, many users will have their configurations in the correct location, and Arcanist can remove the additional behavior in favor of only supporting the “correct” location for arcrc.

Alternatively, an even easier solution would be to have an environment variable like ARCANIST_CONFIG_HOME that specifies the location of the Arcanist config file. This wouldn’t be compliant with the spec, but would be better than keeping the current behavior as is.

but you’d be surprised how many people are bothered by this

As far as I can recall, you’re the only user who has ever raised a concern about this behavior.

If you can provide evidence that a substantial body of Phacility customers find this behavior bothersome and believe fixing it should be among my highest priorities, I’m happy to pursue this change. Maybe you know something I don’t.

The evidence available to me (primarily, the things customers actually raise as concerns through support) suggests that few or no customers care very much about this behavior, and few or no customers believe it is among the highest-impact changes I could make.