-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
⚠️ Follow XDG Directory standard for config/data/... files #6913
⚠️ Follow XDG Directory standard for config/data/... files #6913
Conversation
|
Welcome @cwrau! |
Hi @cwrau. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
The apidiff is failing, but that is expected, what can I do? |
The api diff isn't merge blocking if the maintainers think this is worth merging without an API revision - the check is really informing rather than blocking for API changes so don't worry about trying to pass it :) |
The api diff isn't merge blocking if the maintainers think this is worth merging without an API revision - the check is really informing rather than blocking for API changes so don't worry about trying to pass it - it would be good if you could sign the CLA though 🙂 |
Yes, my boss is working on the CLA 👍️ |
CLA has been accepted 👍️ /help |
Good to hear! I'm not sure what you're looking for with the help tag though 😆 |
I just wanted to add the |
I think we normally only add that label to issues where we want someone to take them up - are you looking to have someone else pick up this PR? If so it might be better to create an issue describing the goals, link this draft PR and then add the help wanted tag. |
Ah, ok, then I misunderstood the point of that label 😅 No, I can keep this PR 👍 |
Ah, I see, yeah, I still need to have the questions answered 👍 By anyone, really 😅 |
Got it. cc @ykakarap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see, yeah, I still need to have the questions answered 👍
By anyone, really 😅
I will take a look at this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like according to XDG documentation if XDG_CONFIG_HOME
is not defined it should default to $HOME/.config
. Meaning, we will effectively move from $HOME/.cluster-api
to $HOME/.config/cluster-api
in the general case.
I do not have strong opinions on doing this move.
Regarding your first question - I think establishing backward compatibility with $HOME/.cluster-api
should be possible. This would also mean unless we break the contract both the XDG_CONFIG_HOME
and $HOME/.cluster-api
will need to be supported.
Regarding your second question - Are you suggesting that we move the dev-repository
location also to XDG_CONFIG_HOME
? If so, It might be easier to just build the support into the script we have. Looks like we dont need all of xdg library to begin with and can just have the logic that reads the XDG_CONFIG_HOME
env var and default to the appropriate value if it is not defined. This would be simpler and would reduce external dependencies. As you pointed out I am not sure if this will be complicated for other OS environments. We will need more information before we can decide.
The documentation will mention to overwrite XDG_CONFIG_HOME while using the script, this could be weird
I am not sure why a user will have to override XDG_CONFIG_HOME
. Can you please explain?
prior art from |
7c7737d
to
101fdf3
Compare
101fdf3
to
e69ace0
Compare
Looks like with a rebase this is good to go. |
e69ace0
to
9c75855
Compare
Only did a high-level review given all the lgtm's above. Looks good to me, just one nit. Thank you very much for the patience, would be great to get this into the next release. |
…. files feat(clusterctl): use XDG_CONFIG_HOME for script as well
9c75855
to
a0d0c1d
Compare
/lgtm |
LGTM label has been added. Git tree hash: 0a1f3bb26081b57b62b2140d39d471cff41080f7
|
Thx! lgtm (from a high-level review) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
Thanks again for following through on this!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: killianmuldoon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
🥳🎉 |
this is following changes to upstream to make it follow the xdg configuration directory. see kubernetes-sigs/cluster-api#6913 for more information.
What this PR does / why we need it: This PR switches the hardcoded paths (
$HOME/.cluster-api
) to be XDG conform ($XDG_CONFIG_HOME/cluster-api
).This removes clutter in the users' home directory.
Open questions:
I tried adding backwards compatibility to the old path inside the
reader_viper.go
but I'm not sure if this works for everythingThe script
cmd/clusterctl/hack/create-local-repository.py
creates adev-repository
at$HOME/.cluster-api/dev-repository
. I see three solutions to this;XDG_CONFIG_HOME
while using the script, this could be weirdI personally vote for the first possibility