Closed ian-h-chamberlain closed 1 year ago
yadm's just a fancy wrapper around git. git config doesn't have any "evaluate the host" stuff. the values you get back from git config
(and thus yadm config
) follow a hierarchy of files within your system.
it doesn't make a lot of sense ( to me ) to incorporate that kind of functionality (specifying it's own collection of default git values or querying systems for their stuff).
You could simply make a bootstrap script ( for yadm bootstrap
) that found those values you want and ran yadm config local.os <value here>
or add them to $HOME/.local/share/yadm/repo.git/config
or your ~/.gitconfig
as part of your setup for the new device.
then all your other scripts that rely on whatever yadm config stuff you want will have the defaults you want
it doesn't make a lot of sense ( to me ) to incorporate that kind of functionality (specifying it's own collection of default git values or querying systems for their stuff).
Doesn't yadm alt
already evaluate this stuff when it's deciding which alts to symlink? Maybe yadm config
isn't the right place for this kind of functionality, but I guess really what I'm asking for is a way to expose the yadm
logic for however it evaluates os
, distro
, etc. as used in an alternate file's ##os.X,distro.Y
directive, so I don't have to reimplement all those things myself and I can easily ensure the resulting values match those used by yadm alt
.
Adding a bootstrap script to set some of those configs would work I suppose, but I'd still have to figure out ways to evaluate some of those things... perhaps by using a yadm template I could just extract the values and re-set them with yadm config
? It feels a little awkward to read values with yadm
and then overwrite them but maybe that's the best option for now.
Edit: looking around and experimenting a little, I also saw some options in #291 and I think this might work for me as a way to inject these values to my shell environment:
│ File: ~/.config/yadm/alt/.config/yadm/env##template.default,extension.env
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────
1 │ # Sourceable environment variables from yadm values
2 │ export YADM_ARCH={{ yadm.arch }}
3 │ export YADM_CLASSES={{ yadm.classes }}
4 │ export YADM_DISTRO={{ yadm.distro }}
5 │ export YADM_DISTRO_FAMILY={{ yadm.distro_family }}
6 │ export YADM_HOSTNAME={{ yadm.hostname }}
7 │ export YADM_OS={{ yadm.os }}
8 │ export YADM_USER={{ yadm.user }}
───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────
This issue has been labeled as stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue was closed because it has been labeled as stale for 7 days with no activity.
Is your feature request related to a problem? Please describe.
Rather than using yadm alts, I sometimes prefer to write scripts that use conditional logic based on the
yadm
config. Forlocal.class
, this works great since I can just write something likeHowever, this only works for manually-set
yadm config
as described in https://yadm.io/docs/alternates#class-and-overrides — the "default"local.*
values simply return an empty string when queried this way, even whenyadm alt
works expected:Describe the solution you'd like
Ideally, running
yadm config local.x
would display either the manually-configured value ofx
, or fall back to the default value (i.e. the host environment value) where possible.Perhaps there is a flag I'm simply missing to force
yadm config
to evaluate the host environment instead of just the$HOME/.local/share/yadm/repo.git/config
values?Describe alternatives you've considered
I could manually run things like
uname
,hostname
etc. to figure out these details, but since I already useyadm
to manage alt files, it would be nice to simply reuse it and get consistent values across all my scripts.At minimum, perhaps a nonzero exit code for a missing config would help indicate that nothing is configured for a given value, although IMO wouldn't be as useful as displaying the value.
It might still be useful to return nonzero for unsupported keys (catch typos), like
local.xyz
in the example above.Additional context
Nothing else comes to mind