Fork me on GitHub
#polylith
<
2022-05-25
>
J20:05:06

Hi guys! Is there a way to indicate an other directory for ~/.polylith/config.edn?

seancorfield21:05:54

That's where I would expect a user-level configuration to be -- although on XDG systems, that should be ~/config/polylith/config.edn -- are you on an XDG system @UHZPYLPU1?

J21:05:23

I begin a migration of my tools on XDG standard.

seancorfield21:05:43

Ah, then open an issue at https://github.com/polyfy/polylith/issues about it and someone (quite possibly me) will do something about it. I agree that if XDG_CONFIG_HOME is set, Polylith should respect that.

seancorfield21:05:00

Looks like it'll need a bit of refactoring to make this change less painful -- right now the code calculates that path all over the place. It needs to be computed in a single place and everywhere else should depend on that. It may also need changes to CI since the script does some setup assuming the non-XDG location -- it would need to take that into account. There's also, potentially, a backward-compatibility issue: if poly suddenly starts respecting XDG, any existing users who have ~/.polylith/config.edn would "lose" their configuration and would need to move it to ~/config/polylith/config.edn manually before poly will work as they expect. Probably needs some discussion with @U1G0HH87L and @U2BDZ9JG3 (and @U08BJGV6E and maybe others) whenever they're next around.

tengstrand05:05:04

I wasn’t aware of XGD_CONFIG_HOME but now when I am, I think we should respect that environment variable. Please create an issue @UHZPYLPU1 or @U04V70XH6 . I haven’t looked into the details yet, but yes, maybe we should have a config component where we handle this, and also refactor some code. We could then release 0.3.0 to indicate that the change is not backward compatible.

2
imre08:05:35

I'm honored to be tagged 🙂 although I haven't done anything related to that config yet either in code or customizing it. As far as I can tell by reading the code, this config file is created if it doesn't exist https://github.com/polyfy/polylith/blob/8586ca47b597d90b24173fce5fefde39e6aeb38d/components/command/src/polylith/clj/core/command/core.clj#L67, so migration from the old file could be done https://github.com/polyfy/polylith/blob/febea3d8a9b30a60397594dda3cb0f25154b8d8d/components/command/src/polylith/clj/core/command/user_config.clj#L12, potentially deleting (in case its contents appear default) or updating the old file with an explanatory comment (in case it appears modified) and warning if both exist and it appears the user is still modifying the old one. I believe this could help make this change non-breaking. One thing I'd also suggest updating is that the path to this config file appears https://github.com/polyfy/polylith/search?q=config.edn, I'd try to introduce a single source of truth for that. (just like how Sean pointed that out)

seancorfield16:05:16

It's true that Polylith could detect the case of an XDG file being missing but the old file being present and migrate it. I wasn't sure if the added complexity was worth it for a one-off file copy/update...

imre16:05:45

Since ensuring the existence of the config file is already carried out on command execution, I think that added complexity wouldn't be too high. Unless one goes crazy checking all the edge cases.

seancorfield16:05:50

If neither file exists, it might be worth creating both on XDG systems, with the "old" file having that comment pointing to the XDG version, to avoid folks following outdated instructions out there on the Internet and trying to update the old file and wondering why it doesn't work...?

imre16:05:00

Isn't reduction of home folder clutter one of the purposes of XDG?

seancorfield17:05:29

https://github.com/polyfy/polylith/issues/227 -- I hope I've captured everything from this discussion there (including your later caveat @U08BJGV6E)

👍 2
imre21:05:51

Perfectly worded, thank you @U04V70XH6!

seancorfield20:05:52

I'm starting to work on this issue and will try to get a PR pulled together maybe today. There are several places in the test code that assume hardcoded paths for the config.edn file (actually /Users/joakimtengstrand/.profile/config.edn 🙂 ) so it'll be interesting to see what happens if the tests are run on an XDG system. I see my Ubuntu instance has a couple of XDG env vars, but not XDG_CONFIG_HOME, and many tools already seem to use ~/.config/<tool>/<files> for their configuration -- on both XDG and non-XDG systems. I'm not an expert on this aspect of operating system conventions so I welcome input from more knowledgeable folks!

seancorfield20:05:37

A note for @U1G0HH87L (and maybe @U2BDZ9JG3): out of the box, the master branch fails on five tests which I believe are all down to how the empty character renders differently on my old US Mac compared to how it renders on your systems?

:empty-character "·"
but it looks like I'm seeing . in the output (that doesn't match) compared to ·

seancorfield20:05:48

Here's a mismatch from one of those failed tests:

"  admin         .  .  .  ."
"  admin         ·  ·  ·  ·"

seancorfield20:05:46

Ah, it looks like, at some point my ~/.polylith/config.edn file was laid down with the "·" version -- was that how it used to be, and it got changed to "." to avoid rendering issues on various platforms? I updated that file and now all the tests pass -- perhaps not ideal to have the tests depend on the local user config data 🙂

imre20:05:05

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html states: > $XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

seancorfield21:05:51

Hmm, so the absence of XDG_CONFIG_HOME does not mean it's not an XDG system... so how should code figure that out?

seancorfield21:05:17

The clojure script only checks XDG_CONFIG_HOME so it's not properly compliant either 😕

imre21:05:05

My knowledge about the area is rather shallow. Gut feeling tells me it's probably well-mannered to default to ~/.config/program/config-file as opposed to outside of ~/.config even if there is no proof wrt the system following XDG. I'm not sure whether this could be a problem

seancorfield21:05:36

So... then maybe this ticket becomes "Change poly tool to follow XDG conventions" and just deprecate/migrate ~/.polylith/config.edn to the new location regardless?

seancorfield21:05:10

I found a simple little Java lib that implements a fair bit of that basedir spec: https://github.com/omajid/xdg-java

imre21:05:12

I would think that's a good approach, where new location is determined by looking at XDG_CONFIG_HOME backed by the standard default

seancorfield21:05:10

The XDG spec explicitly says to rely on $HOME for the home directory but I notice poly's code relies on the user.home system property. This will all fall out in the PR 🙂

imre21:05:44

insert obligatory xkcd about the n+1th competing standard

tengstrand06:05:49

All this sounds reasonable to me! Regarding the empty character problem, I think we should just skip the possibility to configure it and hard code it to “.” (period), but that should be a separate issue.

seancorfield17:05:40

It looks really nice as a raised dot 🙂 But certainly the tests should not affect the local config and should not be affected by it. As you say, a separate issue.

👍 1
tengstrand17:05:37

Merged.

👍 1
1
seancorfield20:05:52

I'm starting to work on this issue and will try to get a PR pulled together maybe today. There are several places in the test code that assume hardcoded paths for the config.edn file (actually /Users/joakimtengstrand/.profile/config.edn 🙂 ) so it'll be interesting to see what happens if the tests are run on an XDG system. I see my Ubuntu instance has a couple of XDG env vars, but not XDG_CONFIG_HOME, and many tools already seem to use ~/.config/<tool>/<files> for their configuration -- on both XDG and non-XDG systems. I'm not an expert on this aspect of operating system conventions so I welcome input from more knowledgeable folks!