Github issue#491 proposes to use the XDG base directory specification for the personal init file, now called ~/.swiplrc on Unix and the appdata directory followed by SWI-Prolog/swipl.ini on Windows.
It is surely a good idea to adopt platform guidelines, but it is also a nice to be consistent over platforms. It seems most platforms have some standard directory for user preferences. This implies we could opt for e.g.
<platform user preferences dir>/SWI-Prolog/init.pl
and we could also place the personal library and personal packages there in subdirs pack and lib.
The Preferences dir is than:
WIndows: appdata
MacOS: /Users/username/Library/Preferences
Other Unix: $XDG_CONFIG_HOME if present and ~/.config otherwise.
Would that make sense? Is the cleanup worth the trouble it will cause? Opinions?
In the case of macOS, the /Users/username/Library/Preferences directory seems to be mainly used for native GUI applications. For command-line applications, I’m not aware of any Apple specific guidelines. Looking into my home directory, I find dot files for all kinds if applications, including some GUI ones.
I assume that any update to follow platform guidelines will still continue to also look into the traditional places (using a well documented search order)?
In issue#491 it notes using XDG base directory which as far as I can see is for Linux based systems only. However the quote seems to imply that XDB base directory also covers appdata in Windows. Am I correct that Windows appdata is not part of XDG base directory?
In the proposal the directory for Windows stays the same, but the file name would be changed from swipl.ini to init.pl. The directory comes from win_folder(appdata, AppData). (win_folder/2) (GitHub)
I guess on MacOS, most non-native GUI applications come from the traditional Unix world using ~/.progname as default location. For real Mac apps they use a dedicated directory. The advantage of a dedicated directory is that we can use consistent file naming conventions for personal Prolog files. I think Linux is leading in how traditional Unix commands are managed, which might also introduce .config to MacOS
Provided we think this is a good idea the second question is indeed how to migrate? Looking in both the new and old place is an option. The big disadvantage in my experience is that people somehow get a file in both the new and old place, edit the one in the old place and see no effect. Loading both is yet another option, but as the file is typically not a module file and tends to define the same stuff this will cause redefinition warnings. A warning is another option, but typically makes it hard to have an old and recent version of Prolog around and use both without warning.
Apple uses a BSD-derived sub-system. Moreover, unlike Linux, native macOS applications don’t run on top of the BSD sub-system. Given past Apple policies, I would be quite surprised it they adopted something like .config.
Also using a settings file in Logtalk, my solution is to print at startup by default if a settings file was loaded and if so from where. E.g.
%
% Loaded settings file found on directory /Users/pmoura/
%
When no settings file is loaded, the printed text explains where settings files can be found:
%
% No settings file found in the startup, Logtalk user, or user home directories.
% Using default flag values set in the backend Prolog compiler adapter file.
%
This solution is easy to implement also in SWI-Prolog.
As I do some research on this I am posting my notes/links here so that others who are interested don’t have to do the same work. I am also making this a wiki so anyone with the privilege can edit and add to it.
These are only related to Windows OS.
Directory
On my Windows system using SWI-Prolog (threaded, 64 bits, version 8.1.12)
So I am satisfied that the directory name is fine. That is not to say I think it is fully in line with the Microsoft specification, as I don’t even know the full Microsoft specification, nor can I find it online.
File name
The name change from swipl.ini to init.pl also makes sense because on Windows, an ini file type is a fairly standard format (Wikipedia) and the contents of swipl.ini is obviously not an ini file but Prolog code. A common file type for Prolog code is pl (pl file type)
So I am satisfied that the file name change would be a good thing.
Migration
I view it as possibly three configuration sets.
init.pl
swipl.ini
default settings used if 1 or 2 have any invalid settings.
The system should try and find the configurations in the order listed. If one is found then it should be checked to make sure it is valid. If not valid, move onto the next configuration. If it is valid it is used.
Anything other than just init.pl existing, being valid and used should result in a warning message(s).
I don’t think the system should try and reason out if two options exist in two files and conflict then what to do. The system should look at an entire configuration as either valid or invalid and leave the problem of deleting a file if necessary or migrating the individual options from one file to the other to the user. The user should get messages about there being two files, but not much more. The messages should not note details lower then an entire configuration as that might confuse new users.
IMHO, the goal is to get SWI-Prolog up an running, not stop if a bad configuration file, conflicting files, missing files, etc. The startup process should not be about sending lots of messages, nor is it about trying to teach a user how to resolve this problem. The process should not make any changes to the file, or delete an file, leave that up to a user.
Indeed. People providing applications via Macports and Homebrew are quite likely to do so though.
Once upon a time such a message was printed. Later I silenced all compilation messages by default and this also killed the message showing the compiled init file. I haven’t seen any complaints on this and thus my working assumption is that most users want the system to be mostly silent.
Had a look on my Mac after building the 8.1.14 binary. The Mac is pretty much empty It seems that
As Paulo claims, ~/Library/Preferences is only filled with *.plist files. That doesn’t seem to be a good place. The SWI-Prolog app already has a place there and that seems to be all we should put there.
Most non-mac applications have a ~/.program dir (some ~/.program.d) and/or ~/.programrc file
FileZilla uses .config/filezilla (dir).
So, if we want to go for a configuration directory on every platform the most obvious choice on Unix seems to be $XDG_HOME_DIR/SWI-Prolog, defaulting to ~/.config/SWI-Prolog. This directory should contain
The init file
The personal library
Personal packs
It does make some sense to me as it seems to improve consistency over the platforms and fits with more standards. I’m still easily convinced to keep everything as is as well though
On behalf of all Linux users with abused home directories full of dotfiles, yes please!
I count 20 dotfiles in my home directory that shouldn’t be there, including my 2 line .swiplrc. As a Linux user trouble is minimal, I’ll just use a soft link from ~/.swiplrc to ~/.config/SWI-Prolog/swiplrc during a transition period using multiple versions, but that won’t last long seen as updates haven’t broken my existing code yet.
Just to let you know, I completely agree with using XDG on MacOS too! It’s easier to add this for all *nix flavours, and is much easier to sync dotfiles between MacOS and Linux. Please don’t litter our home-dir with ~/.program_dir or ~/.programrc.
This conversation should not only be about the personal init file, but also about the .swipl-dir-history. When using the XDG convention, this directory should be in $XDG_CACHE_HOME which defaults in ~/.cache/. I would suggest using the same name for SWI-Prolog in the config and the cache places, so maybe something like ~/.cache/swi-prolog/<files> and ~/.config/swi-prolog/<files>.
I beliege that swipl should follow the xdg standard:
configuration in $XDG_CONFIG_HOME\swi-prolog
cache in $XDG_CACHE_HOME\swi-prolog
extra data in $XDG_DATA_HOME\swi-prolog (probably not needed)
Seems that on Windows we only have appdata, which is supposed to hold both config and cache data. Now it gets a difficult choice. I very much like using this change to make all platforms behave as much as possible the same. I think a single directory makes more sense. Also because our cache data, being only command line history, is not much.
The cache might not be much, but the data could, especially considering extra packs and libraries (I hadn’t considered them in the previous comment)
Those should ideally go in $XDG_DATA_HOME/swi-prolog (defaults to ~/.local/share/swi-prolog
This would keep the .config root small enough, for example for those who keep it backed up to save the configurations.
I can understand the convenience of having one single directory for both config and data (cache is basically irrelevant in this case), and in that case I believe it should go in $XDG_DATA_HOME, for size reasons.
I’m sorry if my comment is late, just a thought.
Thanks. Thinking a bit, I think most of the files clearly belong in config. Even the optional personal library because it is typically supposed to be small, providing small utilities to personalize interaction during development and debugging. I’d not put real code that is used in your programs there as it makes the program hard to share. Of course, we cannot stop anyone, neither can we stop people writing their application in the init file. I’ve seen it happen
Packs are a different issue. I think the idea of packs installed outside projects, though copied from other systems, isn’t great. Personally, I define packs as git submodules inside the project that uses them. Anyway, some/most people install them outside projects.
I propose to add $XDG_DATA_HOME/swi-prolog/pack as the first (default) option for creating the pack directory. For Windows users we could add
CSIDL_COMMON_APPDATA (shared appdata location)
CSIDL_LOCAL_APPDATA (non-roaming appdata)
The latter is (I think) comparable to XDG_DATA_HOME
I can’t say anything about the windows paths,
But the idea of splitting the paths like you say seems good.
I agree that packs in $XDG_DATA_HOME/swi-prolog/pack
and config + personal libs in $XDG_CONFIG_HOME/swi-prolog
makes sense.
This is much better, packs are not ‘configuration’, but libs can be considered ‘configuration’ since they should be personal preds to make development easier or some such things that are not part of the application being developed.