Open ross-spencer opened 8 months ago
For reference: Similar comment in closed issue #25, see https://github.com/steffenfritz/FileTrove/issues/25#issuecomment-1924822964
Use case: Installation of ftrove in /usr/bin and data somewhere else
General impacts: (i) Installation has to be rewritten and (ii) installation becomes more complex for the user
I see four possibilities, with different chances and problems:
one flag for an application root, where db and logs are expected, nsrl.db, siegfried.sig and filetrove.db must be in db (+) Data and version(s) are coupled (+) Projects can have their own folders (-) less flexibility (-) nsrl.db has to be linked/copied manually
two flags, one for db and one for logs (like mentioned in the referenced issue). Here is the idea to keep the binary and the NSRL coupled. (--) makes no sense with the above premise
two flags, (i) one for root (like in 1.), coupling logs and db with filetrove.db and siegfried.sig, and (ii) one for the nsrl.db (+) Flexible (+) Reuse of NSRL (+) Installation paths clear for users (-) No coupling between nsrl data and version (at least the versions are stored in filetrove.db)
four flags: nsrl.db, _filetrove.log, filetrove.db, siegfried.sig (+) Flexible (-) Scattered installations
For 1), 3) : During installation a env/toml/... file could be created in a root directory and if ftrove is run again, e.g. for listing sessions, this could be read and all "flag" information is stored there.
For 4): A general configuration file, e.g. in ~/.config, has to be used as there is no project root.
Probably I missed some combinations but from the above I think 3) is the best one. We could also have the nsrl.db location defaulting to db directory, like it is today.
On the other hand: ftrove is a statically linked binary that lives alone in a directory with just a few MB. To keep the data and the binary coupled is also not too bad (and was the idea in the first place). While I see the necessity to reuse nsrl.db, maybe we can leave everything as it is while add an optional location flag for nsrl.db?
For configuration a dotfile seems great, the potential for XDG compatible directories might be worth investigating? (nb. I haven't enough experience with them yet so I need to brush up on that)
As for the use-cases, then the potential to reuse the NSRL database seems like an exciting one.
Where filetrove and its databases sit is less of a problem once the user can customize the configuration, e.g. my golang apps all install to one location that is on the $PATH
so I might not co-locate these files but if I'm reading from a config it doesn't prevent me from using a number of different layouts.
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Install allows a user to specify an installation directory but filetrove uses hard-coded paths to determine locations, e.g. in the diff below I have tried to demonstrate each affected path on application startup with my own tmp path (the list isn't exhaustive):
Describe the solution you'd like A clear and concise description of what you want to happen.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Leaving the code as-is will likely break use anywhere that isn't a standalone use of the tool, e.g. installed from
/usr/bin
where the user probably doesn't also want to install filetrove's static files there.