Maybe move default storage dir outside nethermind repo folder?

[obasekiosa]

Is your feature request related to a problem? Please describe.
Deleting an entire repo implies deleting all storage data when nethermind client is ran from source.

Describe the solution you'd like
maybe have client use the HOME fould of XDG* paths for creating these directories.

Describe alternatives you've considered
Just let it be. it shouldn't be an issue.
allows running multiple versions of the code without worrying about data collision.

Additional context
None.

[Dhir0808]

Hi @obasekiosa , I suggest changing the default storage directory to use the HOME directory or XDG paths (e.g., $XDG_DATA_HOME, $XDG_CONFIG_HOME). This would prevent data loss when deleting or updating the repo and avoid conflicts when running multiple client versions. It would also give users more control over where the data is stored.

I would like to take this issue.

[obasekiosa]

@Dhir0808
Sure.
it'd be nice if you start a conversation about it first

I'd just link a couple of people.
@MarekM25
@LukaszRozmej @damian-orzechowski @rubo

[Dhir0808]

Hi so what I propose is
first we need to define the standard paths following XDGs specs then provide configuration options for custom paths and ensure a backward compatability

so we can create a new class to handle the storage paths
then update the db config to use new path and
then add migration for the existing data
also we will need to update the startup config to handle new paths

[obasekiosa]

Hi so what I propose is first we need to define the standard paths following XDGs specs then provide configuration options for custom paths and ensure a backward compatability

so we can create a new class to handle the storage paths then update the db config to use new path and then add migration for the existing data also we will need to update the startup config to handle new paths

@Dhir0808
The goal is to change the default location.(i.e the location that is used if none is specified.
basically change the location of the storage path to be that specified by the os based on the env variable XDG*

pick the approprained XDG* variable and reasonable fallbacks should they be empty.
also consider how the changes would affect release mode/binary.

[Dhir0808]

@obasekiosa I have tried to move the folder out can you have a look at it and suggest any changes,
it has given me an auth error when I tried to run the app but that maybe because I dont have access to DB ig.

[rubo]

I have mixed feelings about this. While it may make sense in certain situations, it doesn't address a common issue. Previously, we had the NETHERMIND_DATA_DIR environment variable for this very reason, but it didn't get much use across the team, so we removed it.
This said, I don't consider frequently checking out and deleting the repo a typical use case. Usually, when running Nethermind, one should explicitly specify the data directory pointing to a dedicated storage place. That should resolve all the problems.

[obasekiosa]

@obasekiosa I have tried to move the folder out can you have a look at it and suggest any changes, it has given me an auth error when I tried to run the app but that maybe because I dont have access to DB ig.

@Dhir0808 this is actually quite good.
But a bit overkill.

What we would have wanted was to simply get the env variable and recursive fallbacks if any are empty and then set the
config baseDb path to the first non empty value.

Also we could do away with the "Nethermind" prefix when naming classes.

But given @rubo concerns which i believe are valid.

A better approach would be to just log a warning on startup that the default directory is being used [and would be lost on deleting the repo (might not make sense when using a compiled binary)].

what do you think @rubo @Dhir0808

[Dhir0808]

@rubo @obasekiosa Thank you for the feedback! I will start to work on logging a warning on startup which is I feel a good solution to the problem.

[rubo]

The priority is end-user experience, not the dev team. While the data directory should always be explicitly set, and showing a warning makes sense when it's not, I'd like to know the team's opinion about this.