.springrc location

[varikonniemi]

Hello, i have a quick question about .springrc

Why is it found in ~/.springrc and not in ~/.spring/.springrc ?

You might call it ocd, i call it keeping things nice and tidy. Should not one directory under home be enough for spring?

[abma]

because in .springrc you can set the path of this folder.

[varikonniemi]

So if you want to have that folder somewhere else, why cannot there also be one in ~ with only .springrc left inside of it?

To assume .springrc is found in ~/.spring instead of ~ where it is currently assumed would reduce the clutter generated by spring by at least 50%

:)

[varikonniemi]

So no real answer to this question?

So let's try again:

why cannot .springrc be moved to ~/.spring so all spring clutter in home directory would be confined to one place?

[varikonniemi]

double

[Forboding Angel]

Because springrc needs to be in a place where it can always be found because it tells the location of where to store the spring stuff (defaults to .spring).

[hoijui]

that is not the reason. if we would have to ensure the file is alwyas there for each user that might run spring, which we can not, and should not, then it wold not make a difference whether we had to ensure it is in ~/ or in ~/.spring/
i don't know why it is in ~/ and i kind of agree that it would be more *nix standard to have it in ~/.spring/ instead. the general rule i see, is if the application uses a dir at all, the config file should be inside the dir.
i guess it could evne be changed now, but ... there is probably too little gain (basically only adhering to the standard) , for anyone to take upppon himself the trouble: after next release: WHAAAAA all my settings are gone!!! spring i hate you!!!!
or if we allow both locaitons, people will get confused about which one is correct now, and after some time we will have to remvoe the old locaiton anyway.
but well.. i woudl sya it is ok to move the main location to be something like ~/.spring/config.txt, and still look for ~/.springrc for a few releases, maybe can be decided in a meeting.

[varikonniemi]

I don't see why copying .springrc content to config.txt could not be part of the upgrade procedure?

So lost configs should not be a problem imho.

Just because something has been done one way does not mean it has to be done like that forever. Fedora did a big decision to clean up their filesystem tree, i think spring could do this step in the same spirit, if there are no real downsides to it.

[hoijui]

you need problem?
one can have, and more and more will have multiple enginve versions installed and at use at the same time.

[jK]

We should follow XDG standard (note the fallback values in the "Environment variables" section if vars aren't set).

Also a question is if spring should follow an "all in one folder" policy or split config, cache & data?

[varikonniemi]

you need problem?
one can have, and more and more will have multiple enginve versions installed and at use at the same time.

How does the move of .springrc into .spring/ affect the ability to have multiple engine versions installed?

[dansan]

We should follow XDG standard (note the fallback values in the "Environment variables" section if vars aren't set).

Also a question is if spring should follow an "all in one folder" policy or split config, cache & data?

Cannot find anything about multiple versions of the same software there...

My idea would be:

Code: Select all

.config/springrts/springrc
.config/springrts/uikeys.txt
.config/springrts/0.88/springrc
.config/springrts/0.90/springrc
.config/springrts/0.90/uikeys.txt
.cache/springrts/paths/
.cache/springrts/SpringLobby/
.local/share/springrts/demos/
.local/share/springrts/maps/
.local/share/springrts/mods/

Config settings from specific engine versions would overwrite the settings in the main config dir.

The demos folder could have engine-version-dirs too, but the version is also in the filename, so that would be just makeup.

What about the pathfinder cache? Does it invalidate each version, or just sometimes? If it's each release, than subdirs would make sense. It'll allow to switch versions w/o loosing the pathing cache. In the other case file-internal metadata should be added. I still see chat msg about "[desync warning] path... checksum...." that could be avoided with some version magic.