[FEATURE] additional (and optional) system-wide configuration path PREFIX/etc/direnv #1038
Conversation
brandung-sjorek
force-pushed
the
feature/system-wide-configuration-path
branch
3 times, most recently
from
a154be8
to
9795a99
Compare
brandung-sjorek
force-pushed
the
feature/system-wide-configuration-path
branch
2 times, most recently
from
fda644a
to
9799e7f
Compare
brandung-sjorek
force-pushed
the
feature/system-wide-configuration-path
branch
3 times, most recently
from
d277508
to
6bba2bc
Compare
|
@zimbatm I'm sorry to bother you, but I'd really appreciate any feedback on this PR. The change might not be of much value in the Nix world, but it would really help me to initiate a transition to it in my company. Thanks for your work so far, anyway … |
There was a problem hiding this comment.
I'm eager to review this PR, but I've noticed several changes that seem unrelated to the new feature, as well as numerous code style modifications. In the future, it might be best to keep such changes separate from new feature introductions for the sake of clarity and easier review. Don't you think?
|
@drupol Sorry, but I don't think that there are unrelated changes or code-style modifications. Please, take a look at my summary of changes in the PR description and tell me what to drop from the PR. I'm curious - what make's you think there are unrelated or style changes ? Could you please give me an example? Nevertheless, thanks for your feedback! |
There was a problem hiding this comment.
@drupol Are these the unrelated changes you're talking about?
|
@drupol Ok, I understand and agree - I'll change that this evening - 08:00 PM CEST |
|
Take your time and thanks for your collaboration. |
…EFIX/etc/direnv Signed-off-by: Stephan Jorek <stephan.jorek@brandung.de>
brandung-sjorek
force-pushed
the
feature/system-wide-configuration-path
branch
from
6bba2bc
to
e180c33
Compare
|
@drupol I removed the code-style changes from the PR. Now, I ask myself what to do next? There are still changes in there, that are technically not needed, for example …
… and maybe more. How do we want to deal with those changes. To my mind I would keep them. |
| direnv_config_dir="${DIRENV_CONFIG:-${XDG_CONFIG_HOME:-$HOME/.config}/direnv}" | ||
|
|
||
| # Where system-wide direnv configuration is stored | ||
| direnv_sysconfig_dir="${DIRENV_SYSCONFIG:-/etc/direnv}" |
There was a problem hiding this comment.
My gut feeling tells me that this should be XDG spec compliant, eg.: /usr/share/direnv or /usr/local/share/direnv, but essentially $prefix/share/direnv.
Definitely XDG_DATA_DIRS compliant. /etc/direnv is definitely not XDG spec.
| @@ -138,8 +138,10 @@ things. | |||
| Exporting variables by hand is a bit repetitive so direnv provides a set of | |||
| utility functions that are made available in the context of the `.envrc` file. | |||
| Check the direnv-stdlib(1) man page for more details. You can also define your | |||
| own extensions inside `$XDG_CONFIG_HOME/direnv/direnvrc` or | |||
| `$XDG_CONFIG_HOME/direnv/lib/*.sh` files. | |||
| user-specific extensions inside `$DIRENV_CONFIG/direnvrc` or | |||
There was a problem hiding this comment.
Should still respect XDG spec and refer to XDG spec IMHO.
The PR implements additional (and optional) system-wide configuration path PREFIX/etc/direnv.
Motivation
My original motivation was to distribute some direnenv-extensions (for use in our company), with package-managers like
dpkg, Homebrewbrew, MacPortsportand the belovednix. Currently the situation with direnv-extensions is cumbersome and difficult, as installation of files into~/.config/direnv/lib/*.shis not possible, and alternatives like creating symlinks to system-wide provided extensions appear to be somehow error-prone.After glimpsing into direnv's sources I thought, it might be a good idea to implement this posix-like behaviour for the whole configuration.
I could elaborate in depth on the PR, but I think the actual changes enlighten you more.
Summary of changes
SYSCONFDIR(=PREFIX/etc/direnv) at build-time inGNUmakefileand integrate it into thedirenv-binarySYSCONFDIRindirenv stdlibdirenv.tomlfromSYSCONFDIRSYSCONFDIR-related runtime-configurationsource …-inclusions tostdlib.shSYSCONFDIRruntime-configuration files, add them tomake installI'd be glad to get your opinion and feedback on this PR. And I'd be really happy if the PR or something similar gets merged (or if someone proposes another solution to my original motivation).
Cheers and
Happy new year!