Skip to content

Implement XDG base directories #120

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

Open
mildred opened this issue Sep 24, 2014 · 10 comments
Open

Implement XDG base directories #120

mildred opened this issue Sep 24, 2014 · 10 comments
Labels
need/triage Needs initial labeling and prioritization

Comments

@mildred
Copy link
Contributor

mildred commented Sep 24, 2014

See: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Basically:

configuration should be searched in:

  • XDG_CONFIG_HOME/go-ipgs/config
  • XDG_CONFIG_DIRS/go-ipgs/config

Some rules :

  • XDG_CONFIG_HOME defaults to HOME/.config when not set
  • XDG_CONFIG_DIRS defaults to /etc/xdg when not set

The same logic applies to persistent data files (the one we want to keep) and cached data files (the one we may delete at any moment)

@mildred
Copy link
Contributor Author

mildred commented Sep 24, 2014

@jbenet
Copy link
Member

jbenet commented Sep 24, 2014

I don't agree with this setup. the only path needed is the root of the repo/config, which will have a default location but be changeable with a flag (and maybe an env var). Everything else needed will be defined in that file. Sorry! Thanks though.

@jbenet jbenet closed this as completed Sep 24, 2014
@jbenet
Copy link
Member

jbenet commented Sep 24, 2014

(we can revisit this in the future if there is a strong need to do so)

@mildred
Copy link
Contributor Author

mildred commented Sep 25, 2014

There is nothing preventing the configuration file to be stored in a standard location, is there ?

And is there anything against putting the database in a standard location unless a specific location was specified in the configuration file.

ariescodescream pushed a commit to ariescodescream/go-ipfs that referenced this issue Oct 23, 2021
Only retrieve one value when fetching public key from DHT
@Winterhuman
Copy link
Contributor

Winterhuman commented Sep 6, 2022

@Stebalien Any chance this could be re-opened? Kubo is one of the few applications which doesn't store config files in ~/.config in my case (specifically to check for ~/.config/ipfs first, then fallback to ~/.ipfs, if moving the default location isn't really viable)

Kubo equivalent to: n0-computer/iroh#218

@Jorropo Jorropo reopened this Sep 6, 2022
@Jorropo
Copy link
Contributor

Jorropo commented Sep 6, 2022

@Winterhuman actually any reason you can't just use IPFS_PATH ?

@Jorropo Jorropo closed this as not planned Won't fix, can't repro, duplicate, stale Sep 6, 2022
@Winterhuman
Copy link
Contributor

Winterhuman commented Sep 6, 2022

@Jorropo Using IPFS_PATH wouldn't be the same, it's about making ~/.config/ipfs be detected by default alongside ~/.ipfs (basically the equivalent to IPFS_PATH=.config/ipfs,.ipfs as the default mode)

@Stebalien
Copy link
Member

I'd personally like this to happen, but I'd start out by defaulting to ~/.ipfs for now so as not to break a bunch of tools (by default).

However, I won't be working on it. I'll open it up so it can be triaged, but it may be closed again as "not a priority"

@Stebalien Stebalien reopened this Sep 6, 2022
@Stebalien Stebalien added the need/triage Needs initial labeling and prioritization label Sep 6, 2022
@Jorropo
Copy link
Contributor

Jorropo commented Sep 6, 2022

I'll vote for this to be classed P4, Help wanted.

@alichtman
Copy link

alichtman commented Apr 7, 2023

Having kubo respect the XDG spec would be great. I try to keep my home directory clean, and the $HOME/.ipfs directory that's currently created by default could be placed elsewhere.

$ ls ~/.ipfs
 blocks
 datastore
 keystore
 config
 datastore_spec
 version

config, datastore_spec and version all seem config-related, and could go in $XDG_CONFIG_HOME/ipfs/.

blocks, datastore and keystore all seem data-related, and could go in $XDG_DATA_HOME/ipfs/.

Keeping ~/.ifps as the first path searched to maintain backwards compatibility makes sense.

For new installations (where ~/.ipfs does not exist and $IPFS_PATH is unset), we could set these new defaults. And the migration path for users would look something like:

$ mkdir -p $XDG_CONFIG_HOME/ipfs
$ mkdir -p $XDG_DATA_HOME/ipfs
$ mv $HOME/.ipfs/config $HOME/.ipfs/datastore_spec $HOME/.ipfs/version $XDG_CONFIG_HOME/ipfs
$ mv $HOME/.ipfs/blocks $HOME/.ipfs/datastore $HOME/.ipfs/keystore $XDG_DATA_HOME/ipfs

For now, as a workaround, I'll probably set $IPFS_PATH to $XDG_DATA_HOME/ipfs. However, this seems to break the XDG spec since the config is being mixed with data.

I am a pretty new user to ipfs, so it's possible it makes more sense to keep all of these files together in one of $XDG_CONFIG_HOME or $XDG_DATA_HOME. Happy to hear more thoughts on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization
Projects
None yet
Development

No branches or pull requests

6 participants