Location of .fossil
(1) By anonymous on 2020-04-17 12:26:31 [link] [source]
As written in the documentation, global settings are stored in $HOME/.fossil on Unix computers and in %LOCALAPPDATA%/_fossil on Windows computers.
The specifications of macOS tell us that such a file should probably go under $HOME/Library/Preferences and the XDG specifications for Linux tell us that it should go in $XDG_CONFIG_HOME (which defaults to $HOME/.config).
There has been a wide mouvement of ‘$HOME decluttering’ among many open source projects including git. Would it be possible to change Fossil default config file location?
(2) By Richard Hipp (drh) on 2020-04-17 15:36:27 in reply to 1 [link] [source]
I've been doing unix for 36 years, and I've never heard of any of this before. I glanced through the documentation, quickly, and my first impression is that this is all an attempt to make unix more "friendly" to point-and-click users, and the expense of command-line users. In other words, the $XDG goal is to support GUIs and applications that you downloaded from an App-Store. For those of us who were raised on Unix PWB (Programmers Work-Bench) and who view unix as the world's greated IDE, this seems like needless and pointless complication.
How badly does my initial impression miss the mark?
(3) By Larry Brasfield (LarryBrasfield) on 2020-04-17 16:00:00 in reply to 2 [link] [source]
You have not missed the mark at all for any Unixen I know of. (I've used quite a few, starting with SCO running on a PDP-11.)
You would even be on the mark for "MacOS" (or whatever rock or animal it is now), if you were running on the real, BSD OS that is buried within it.
Those decluttering recommendations make some sense, when following them works to the benefit of people challenged by a mouse with more than one button. But since files and directory names with leading '.' are conventionally hidden from that cohort, I see no reason to depart from the now well-established convention on Unixen (and becoming established among Windows applications) where config data goes into a single ~/.whatever file or directory. It's simple, and the first place to look when you cannot find the docs or bother with them.
(4) By Warren Young (wyoung) on 2020-04-17 18:24:15 in reply to 2 [link] [source]
How badly does my initial impression miss the mark?
It's a shift in defaults over the past 20-ish years, mainly affecting macOS and Linux, rather than traditional Unix.
I wouldn't mind if Fossil behaved as OP suggested.
I originally thought we might have a problem with old posts/docs referring to ~/.fossil
but there really isn't a whole lot of that. There just isn't a lot of cause for someone to go referencing that file manually.
The only times I can think of someone speaking of it, it's as a black box, which we could solve by adding a command to make Fossil tell you where that file is here. Then instead of referring to ~/.fossil
, you refer to $(fossil global-config)
or whatever.
That said, this feels very much like someone's personal itch, not something to be imposed by popular will on volunteer developers. If someone contributes a branch for it, and it works, my only concern is that it continues to fall back to ~/.fossil
for existing installs and for systems where $HOME
is the correct place for such things. (e.g. The BSDs.)
(7) By anonymous on 2020-04-17 22:59:23 in reply to 4 [link] [source]
I use Linux, and yet, I don't use XDG and desktop environment stuff. Best perhaps is to check for the XDG environment variables and if they do not exist, continue to use ~/.fossil
instead. This way it will work on both Linux and on BSD.
(5) By Jacob MacDonald (jaccarmac) on 2020-04-17 21:45:44 in reply to 2 [link] [source]
The main complaint I've seen doesn't have so much to do with accessibility as it does with isolating configs so they can be moved around more easily. Which is desirable as various tools which you might want to do this with become more popular (configs checked into SCMs to be shared across machines, Docker, Nix/Guix, etc.).
As Warren noted, it's also part of a shift in FS organization on Linux, and, as more programs put their data in $XDG_*_HOME
, the ones that don't begin to stick out.
And, of course, the spec is designed around (multi-)desktop integration. I, for one, use both GNOME and KDE regularly.
(6) By anonymous on 2020-04-17 22:56:35 in reply to 5 [link] [source]
I personally do not use any desktop environment and do not like much of the XDG stuff. Programs should be written to work even if a desktop environment is not installed, even though some users might use it, so it shouldn't break it either.
(9) By george on 2020-04-17 23:37:10 in reply to 5 [link] [source]
Yeah... Someone may want to distribute Fossil as a part of some portable container (Flatpak and alike) in which case compliance with $XDG_* (and OpenDesktop in general) might save from the headaches.
Fossil could stick to ~/.fossil if it already exists, but otherwise consider a more contemporary location.
(8) By anonymous on 2020-04-17 23:30:33 in reply to 1 [link] [source]
It may not be a general solution for everyone; but if you export the environment variable FOSSIL_HOME with the suitable value of $XDG_CONFIG_HOME on your system, fossil will deal with a .fossil file in that directory instead of in the HOME environment variable value. That may be a suitable immediate-term solution, until (if ever) the fossil binary is changed to access the first-existing of a (potentially) ever-increasing list of directories that may depend on kernels (or libcs) and versions. (And if it does do that, perhaps the file should be $XDG_CONFIG_HOME/fossil, and not $XDG_CONFIG_HOME/.fossil? I'd suggest that the filename is an implementation detail; although in the case of fossil, it wants the directory to be writable, so maybe you want the file to be $XDG_CONFIG_HOME/fossil/.fossil? In that case -- still no code changes needed; just set FOSSIL_HOME to the value of $XDG_CONFIG_HOME/fossil)
(11) By Jacob MacDonald (jaccarmac) on 2020-04-18 01:09:23 in reply to 8 [link] [source]
This seems to be the best solution. The config location can be determined by various packaging systems rather easily, and no one needs to maintain desktop-compatibility code that they would prefer not to.
(10.1) Originally by Richard Hipp (drh) with edits by Stephan Beal (stephan) on 2020-04-18 00:41:25 from 10.0 in reply to 1 [link] [source]
Ugh. Does this check-in appease those who hunger for XDG compliance?
(edit by Stephan: fix link to main repo, not the forum.)
(12) By george on 2020-04-18 02:02:51 in reply to 10.1 [link] [source]
Nice. However in the case of $XDG_CONFIG_HOME
, fossil.sqlite
seems more reasonable to me. I don't hunger that much, though :)
(13) By anonymous on 2020-04-19 09:16:28 in reply to 10.1 [link] [source]
Just as a side note -- please do flag that in the release notes as a potentially breaking change (unless I'm misreading the code). (Also note - a follow-up commit changed the .fossil file name too.) Per wyoung: """my only concern is that it continues to fall back to ~/.fossil for existing installs""" -- I think that this does not do that. (And, arguably, should not do that, for ongoing-code-complexity reasons.) If you have a system which already defines XDG_CONFIG_HOME, and you have not gone out of your way to define FOSSIL_HOME, then when you start using new-fossil, your current ~/.fossil will be silently ignored. "mv $HOME/.fossil $XDG_CONFIG_HOME/fossil.db" may be useful advice if both variables are set. But if you ever later use an old-fossil binary, your new fossil.db will be silently ignored -- even if you set FOSSIL_HOME, because the filename has changed too. So probably the best advice for the release that includes this change, is to declare loudly that this is a change that might need manual intervention if XDG_CONFIG_HOME is ever set; and that some manual file copying between .fossil and fossil.db will be needed if old and new fossil binaries might be used on the same system with XDG_CONFIG_HOME set, unless FOSSIL_HOME is always set (to ensure that the filename remains .fossil). It's complicated... :-(
(14) By anonymous on 2020-04-19 11:42:18 in reply to 13 [link] [source]
(Same anonymous coward here, replying to myself...) Actually, it is possibly not as confusing as I first thought. With this change in fossil-new, if you might want to use fossil-old and fossil-new binaries on the same system (as the same user), then you must ensure that either XDG_CONFIG_HOME is never set, or FOSSIL_HOME is always set. When you then later decide that you only want to use fossil-new binaries on this system; if XDG_CONFIG_HOME is (always) set and you want to use it, do the appropriate "mv .fossil fossil.db" once and never set FOSSIL_HOME; else if XDG_CONFIG_HOME is ever set, set FOSSIL_HOME; else set FOSSIL_HOME or not depending on where you want .fossil to be, and never set XDG_CONFIG_HOME. So, a straightforward-ish two-step dance as part of the "add new version" and "decide to never use old version again" choices. And if you do already use FOSSIL_HOME, or if you don't use XDG_CONFIG_HOME at all, then it's a no-step dance. (Oh, and mostly unrelated: there's a small typo on https://fossil-scm.org/fossil/doc/trunk/www/tech_overview.wiki which refers to ~/.config/fossil.conf instead of fossil.db.)
(15.2) By Richard Hipp (drh) on 2020-04-19 15:09:12 edited from 15.1 in reply to 1 [link] [source]
New Configuration-File Location Algorithm
The latest algorithm for finding the location for the Fossil configuration database file is as follows:
- if environment variable FOSSIL_HOME exists → $FOSSIL_HOME/.fossil
- if environment variable HOME exists and if file $HOME/fossil exists → $HOME/.fossil
- if environment variable XDG_CONFIG_HOME exists → $XDG_CONFIG_HOME/fossil.db
- if environment variable HOME does not exist → ERROR
- Otherwise $HOME/.config/fossil.db
The idea here is that if you have a traditional ~/.fossil file, Fossil will continue to use that file. But you are running Fossil for the first time, it will create a new configuration database file in ~/.config/fossil.db. I think this approach provides both backwards compatibility and XDG compliance.
Further Enhancement
Even as I was writing up this post, it occurred to me that the following algorithm might be better:
- if environment variable FOSSIL_HOME exists → $FOSSIL_HOME/.fossil
- if environment variable HOME exists and if file $HOME/fossil exists → $HOME/.fossil
- if environment variable XDG_CONFIG_HOME exists → $XDG_CONFIG_HOME/fossil.db
- if environment variable HOME does not exist → ERROR
- if directory $HOME/.config exists → $HOME/.config/fossil.db
- Otherwise $HOME/.fossil
This proposed enhancement only uses the XDG name if:
- The traditional ~/.fossil file does not exist
- XDG_CONFIG_HOME is not defined or directory ~/.config exists
I think I might go back in and change the algorithm to this new proposal.
It is so. See check-in
8388a4680f9e2db4
(16) By Richard Hipp (drh) on 2020-04-19 15:52:12 in reply to 15.2 [link] [source]
Another description of the algorithm:
Condition | Filename |
---|---|
1. variable FOSSIL_HOME exists | $FOSSIL_HOME/.fossil |
2. file ~/.fossil exists | ~/.fossil |
3. variable XDG_CONFIG_HOME exists | $XDG_CONFIG_HOME/fossil.db |
4. directory ~/.config exists | ~/.config/fossil.db |
5. otherwise... | ~/.fossil |
I think this provides XDG compatibility on new installs without breaking older installs, even on XDG-configured systems. It should just work. If you have both "fossil-new" and "fossil-old" installed on your system, they should both use ~/.fossil. If you upgrade so that only "fossil-new" is installed on your system and want to start using the XDG-named file, simply run:
mv ~/.fossil ~/.config/fossil.db
(17) By geburashka on 2020-04-20 00:35:46 in reply to 16 [link] [source]
I've seen this exact scheme used by a few projects so thumbs up.
(18) By anonymous on 2020-04-20 03:35:41 in reply to 16 [link] [source]
Makes a lot of sense to me.
(19) By Stephan Beal (stephan) on 2020-04-20 15:01:56 in reply to 16 [link] [source]
i'm a little late to the party here, but...
The more common convention appears, based on my systems, to be that ~/.config/XYZ
are app-specific directories. My ~/.config
dirs contain very few files but dozens of dirs (one per app). Perhaps using ~/.config/fossil/config.db
would be the more conventional and future-proof approach, in the off chance that fossil ever gains any additional user-level files. (OTOH, we've gone 13-ish years without needing additional files, so maybe an extra level of directory is superfluous.)
(20) By Richard Hipp (drh) on 2020-04-20 15:12:12 in reply to 19 [source]
I think the directory approach is used by applications that are using the filesystem as a key/value database. We have a relational database in the ~/.config/fossil.db file, so I don't think we will ever need a directory.