dlang
DUB does not follow XDG Base Directory Specification
(EDIT: Original title: DUB does not follow Filesystem Hierarchy Standard)
Criticism heard on IRC.
<bioinfornatics> dub do not follow Filesystem Hierarchy Standard
<bioinfornatics> and if you follow Filesystem Hierarchy Standard when you install into the home dir prefix should to be ~/.local
I guess it's important for distro packaging.
This is the only thing I found for /home (from http://linux.die.net/man/7/hier):
/home On machines with home directories for users, these are usually beneath this directory, directly or not. The structure of this directory depends on local administration decisions.
I couldn't find any evidence of that statement being true so far and its the first time I hear of ".local". It also doesn't "install" in the sense of a system installation of programs. Maybe he can clarify or provide a reference?
Additional quote from http://www.pathname.com/fhs/pub/fhs-2.3.html#HOMEUSERHOMEDIRECTORIES:
User specific configuration files for applications are stored in the user's home directory in a file that starts with the '.' character (a "dot file"). If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a '.' character, (a "dot directory"). In this case the configuration files should not start with the '.' character.
Using "~/.dub/..." seems to be perfectly in compliance with this.
Linux Specification are describes on freedesktop On given link is wrote:
his specification defines where these files should be looked for by defining one or more base directories relative to which files should be located.
pathname is a global specification for unix based system
Hm I see. But that's just for the X desktop, with which DUB doesn't have anything to do - or not?
That is some rules which programs should to follow to have a cohesive system as dub write file into this system it should follow these rules. I know many project do not follow it mainly because they do not know it.
Even git follow these rules.
little more info:
~/.local is as you define a new prefix i mean instead of /usr/ :
- /usr/bin
- /usr/share …
but for config file they should to go to ~/.config/<appname>
Thank you for listening to me.
OK I clarified a bit with @bioinfornatics, this specification defines some environment variables that are meant to override program directories.
Eg:
local_packages.jsonwould be in $XDG_CONFIG_DIRS- installed DUB packages would sit in $XDG_CACHE_HOME or something.
This was introduced in 2010 to give some flexibility to system administrators, since the home directory became too crowded in some situations, or with too much data.
Git seems to write a single file ~/.gitconfig, at least on all of my systems. But for DUB, if we follow that specification, I think the most appropriate mapping would be:
~/.config/dub/local-packages.json(was~/.dub/local-packages)~/.config/dub/config.json(was~/.dub/config.json)~/.cache/dub/<package>-<version>/(was~/.dub/packages/<package>-<version>/
Since DUB doesn't really "install" anything, it merely caches the packages and build results.
Regarding those environment variables. I've not seen them defined on any system so far. Are they defined system wide, or just within the X session? If the latter is the case, then it wouldn't really be a good idea to use them.
From what I understand, if it these variables happen to be defined, then it replaces the ~/.config or ~/.cache part of these directories. @bioinfornatics right?
That's what I also understood. But if they are only defined inside of the X session, that would mean that DUB would potentially operate on different folders depending on if it's run inside or outside of an X session.
yes exactly but they are not define by default an echo $XDG_ … will return nothing
and definitely using .config and .local is way to do
look on stackoverflow with a similar tool pip from python world :-)
Somebody else brought this up recently. I think it'd be a good idea to move this directory, but don't know how disruptive it would be to existing installs.
In particular the .local/bin part is interesting as it would make binaries usable without invoking dub.
Similarly .local/lib could maybe host shared libraries.
Moving any caches is trivial.
Anyone up for a PR?
I don't know. For libraries it doesn't make sense at all, IMO. There are no ABI guarantees. Even with the same compiler/architecture, the library could have been compiled in multiple possible ways, so that we'd have to make the name unique (similar to the build directories), thus cluttering the directory with opaque versions of the same library. This also wouldn't work on Windows in an analogous way.
For binaries it could make sense to some degree, but please not by default either. Binaries will often need resource files that they expect in their proximity, which would break unless explicitly handled somehow. It would also be a strange side effect to suddenly invoke a different version of a program after a simple "dub build".
All in all, this would be resurrecting the old "install" command, or at least the underlying idea. There are some threads and tickets about this with a number of doubts about such an approach. This is clearly stepping into OS package manager territory.
IMO, the important aspect of this is to separate configuration from downloaded packages and build output files. This doesn't just apply to XDG, but also to Windows, where everything except the configuration files should be in "Local" instead of "Roaming".
I think for a first step towards this this should be pretty simple to implement for someone who knows about these freedesktop environment variables already.
The bootcamp label makes sense on this as the task would basically be:
- change install location to
[cachedir]/dub/packages/*and local-packages and config.json to[configdir]/dub/*(to determine proper paths see https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) - add migration code (with appropriate code stating to remove it later) simply copying (or renaming with copy fallback) the files and folders to the new locations and deleting moved content and also delete the whole old folder if then nothing else is in it
As for the other features like separating binaries on fetch, shared libraries, etc.: they should be discussed in new issues and not be part of this imo, it would be nice moving the files into standard paths first and then discussing about potential new features
Does it make sense to rename the directories though? I have done a similar fix for Q2RTX and we did move the directory, but I am starting to have second thoughts. I think that we should accept $XDG_CACHE_DIR/dub as a location as well as $XDG_CONFIG_DIR/dub, as well as ~/.dub. Users that want to migrate will, but why inconvenience those who are just fine?
Note that we did already do a transition recently, and changed the package cache structure. The inconvenience is actually not very user visible, because it will just lead to a re-download of packages or a missed cache lookup in the vast majority of cases.
What we could do that IMO would make sense is to keep the same default as we currently have, but if the variables are defined, respect them.
Note that we did already do a transition recently, and changed the package cache structure
yes this broke a lot of user's IDE integration for quite a long while as well as introducing other issues, we should avoid it in the future again. I think this probably impacted the workflow of like (guessed) 50% of D programmers using DUB in quite a bad way and certainly will have made some beginners in that time turn away from D due to broken auto complete and other features.