Skip to content
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

Fix dotfiles #8151

Closed
SoniEx2 opened this issue Jan 31, 2019 · 17 comments

Comments

Projects
None yet
10 participants
@SoniEx2
Copy link

commented Jan 31, 2019

Issue type
  • Bug report
Minetest version

OS / Hardware

Operating system:
CPU:

GPU model:
OpenGL version:

Summary

Minetest should follow XDG Base Directory, either by default or with a documented environment variable. This way, it can be listed on, for example, archlinux's XDG Base Directory Support page as either "supported" or "partial", which indicates the minetest team actually cares about standards and user-friendliness.

The biggest benefit of XDG Base Directory is the ability to trivially move all configs and data around. Programs that don't follow it make this task non-trivial. I for example keep my configs on a failing drive and my data on a RAID mirroring setup, but with minetest, it's impossible.

Steps to reproduce
  1. Use minetest on linux
@Calinou

This comment has been minimized.

Copy link
Member

commented Jan 31, 2019

This was already requested in #5217, #864 and #395 but it was rejected.

I would personally support moving to XDG, but it might not be easy to convince everyone; perhaps it would be easier if one opens on a pull request implementing this (with migration/compatibility code to support upgrades from an older version).

@Linuxdirk

This comment has been minimized.

Copy link

commented Feb 1, 2019

I would personally support moving to XDG, but it might not be easy to convince everyone

I wonder how people can be against XDG ... There is no real reason behind not supporting it. It would actually being enough having .minetest moved to $XDG_CONFIG_HOME/minetest.

@Calinou

This comment has been minimized.

Copy link
Member

commented Feb 1, 2019

It would actually being enough having .minetest moved to $XDG_CONFIG_HOME/minetest.

Actually, that doesn't follow the XDG Base Directory specification. For Minetest, it would mandate that:

  • User data like mods and worlds should go to $XDG_DATA_HOME/minetest (falling back to $HOME/.local/share/minetest if the variable isn't set).
  • Configuration files (mainly minetest.conf) should go to $XDG_CONFIG_HOME/minetest (falling back to $HOME/.config/minetest if the variable isn't set).
  • Cache/temporary files should go to $XDG_CACHE_HOME (falling back to $HOME/.cache/minetest if the variable isn't set).

Supporting the XDG Base Directory specification is actually more work than their Windows/macOS counterparts, which typically do not have a separation between user data and configuration directories. If you don't care too much about it, you could dump everything in $XDG_DATA_HOME/minetest (this is what Steam does), but then it's not fully compliant anymore.

Edit: See this comment which clarifies how user data is handled on Windows and macOS.

@SoniEx2

This comment has been minimized.

Copy link
Author

commented Feb 1, 2019

Actually, I'd argue mods are a special kind of configuration file, and should go in $XDG_CONFIG_HOME/$XDG_CONFIG_DIRS. Worlds should go in $XDG_DATA_HOME and world templates (i.e. adventure maps) should go in $XDG_DATA_DIRS.

@paramat

This comment has been minimized.

Copy link
Member

commented Feb 1, 2019

perhaps it would be easier if one opens on a pull request implementing this

Not a good idea if XDG is disapproved, get approval first to not waste your time.
This isn't a bug.

@Calinou

This comment has been minimized.

Copy link
Member

commented Feb 1, 2019

Not a good idea if XDG is disapproved, get approval first to not waste your time.
This isn't a bug.

This might be a little paradoxical (and mostly based on personal experience), but sometimes, opening a pull request before asking for consensus makes it more likely to get it merged. I noticed this when working on primarily opinion-based items in other projects.

This is not a huge feature, so it would make sense here 🙂

@prozacgod

This comment has been minimized.

Copy link

commented Feb 2, 2019

It is a bit paradoxical. It's been my experience as well. I think it's because code can tell the story of what is going to happen better than a conversation about that code. It forces you to think about edge cases and how to deal with them, and then present your process for critique, often when people see an implementation, esp. one that "just works™" there's little to criticise and acceptance is a given.

I do like the idea of following the convention +1

@eli-schwartz

This comment has been minimized.

Copy link

commented Feb 4, 2019

Supporting the XDG Base Directory specification is actually more work than their Windows/macOS counterparts, which typically do not have a separation between user data and configuration directories.

This is factually incorrect. Failure to follow the XDG Base Directory specification or its OS-specific adaptations results in software which is just as broken on macOS and Windows as it is on Linux.

On macOS, XDG_CONFIG_HOME maps to ~/Library/Preferences/, XDG_DATA_HOME maps to ~/Library/Application Support/, and XDG_CACHE_HOME maps to ~/Library/Caches/.

On Windows, XDG_CONFIG_HOME and XDG_DATA_HOME are not separated, as both are in %APPDATA%, but XDG_CACHE_HOME must be in %LOCALAPPDATA% to prevent roaming across network shares (it does not specify when you can clean it up though).

Linux of course provides separate directories for all three (just like macOS), and goes even further by allowing them to be relocated via environment variables. But I hardly see why the lack of cross-platform support for overriding XDG_* should cast doubt on the usefulness of a program intelligently deciding where to put files according to the well-documented, preferred OS-specific locations.

I do know it is very common for people who dislike the work that it involves, to make up stories about how XDG is some weird ridiculous foolish Linux thing and no one other than weird Linux people should care. Which makes this discussion bizarre when the rationale for "don't do it -- it doesn't work on Windows" is coming from a Linux user! o_O

@SoniEx2

This comment has been minimized.

Copy link
Author

commented Feb 4, 2019

honestly both mac and windows have environment variables so we could use them there too, but with different fallbacks for the different platforms :p

@SpaghettiToastBook

This comment has been minimized.

Copy link

commented Feb 5, 2019

Is there any good reason not to do this?

@paramat paramat removed the Possible close label Feb 5, 2019

@paramat

This comment has been minimized.

Copy link
Member

commented Apr 27, 2019

Absence of a reason to not do this is not a reason to do it.

This way, it can be listed on, for example, archlinux's XDG Base Directory Support page as either "supported" or "partial", which indicates the minetest team actually cares about standards and user-friendliness.

Obviously we currently don't ;)

The previous requests were rejected so closing.

@SoniEx2

This comment has been minimized.

Copy link
Author

commented Apr 27, 2019

The biggest benefit of XDG Base Directory is the ability to trivially move all configs and data around. Programs that don't follow it make this task non-trivial. I for example keep my configs on a failing drive and my data on a RAID mirroring setup, but with minetest, it's impossible.

Sorry that this isn't a reason to do it, I guess, even tho it is.

@Linuxdirk

This comment has been minimized.

Copy link

commented Apr 27, 2019

@paramat Since you added “duplicate” please link to the existing issue being about the same thing.

@ClobberXD

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2019

@Linuxdirk #8151 (comment)

This was already requested in #5217, #864 and #395 but it was rejected.

@benrob0329

This comment has been minimized.

Copy link

commented Apr 27, 2019

I would like to ask why this was rejected as "Won't add", when the only dev who has stated to be against it is @paramat, with one even commenting that he was for it.

Using standard data directories is simply sane behavior for any modern application, it makes backups easy, people often know where to look, it doesn't add extra directories to the base of my home folder, and its following standard application etiquette.

No real reasons were given not to add this, and several reason have been given from the start to add this.

@rubenwardy

This comment has been minimized.

Copy link
Member

commented Apr 27, 2019

It's a duplicate of #864
See in there for the reasons

@paramat

This comment has been minimized.

Copy link
Member

commented Apr 27, 2019

benrob0329 the answer was in the post before yours #8151 (comment) and earlier in the thread #8151 (comment)
I also wrote:

The previous requests were rejected so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.