cove always assumes you're in the dist directory

[weebney]

$ pwd
/var/tmp/emptydir
$ ls
$ /path/to/cove
...
2023/08/23 01:49:14 main.go:45: error in main: opening data db: sqlite.Conn.LoadExtension: SQLITE_ERROR: ./dht-indexer-rust.so: cannot open shared object file: No such file or directory
$ ls
ledis  torrents.db  transcoder

Running cove from outside of the dist directory (where the binary and dht-indexer-rust.so are) does not work because it seems to assume that it is only being run in its own directory. As a result, it will create some files & folders in the working directory and will fail to launch because it can't find dht-indexer-rust.so in the working directory.

[anacrolix]

v0.0.8 supports running cove externally. dht-indexer-rust.so must be either in the working directory, or the same directory as the cove binary.

[anacrolix]

Ok this is released.

[weebney]

Could be nice to have the option specify a separate data dir; by default something like ~/.local/share/cove on Linux or %appdata%\cove on Windows.

[weebney]

Just realized this is not fixed entirely—cove still creates a bunch of data files in the working directory. I added a workaround by wrapping cove in a script that moves you to a default data directory, but this really should be managed by cove and not the user.

[anacrolix]

Hmm this is by design. I somewhat opinionatedly believe long running processes should store their state in the working directory otherwise what is it for?

All the files produced in the working directory are cache files for now, so you could cwd to the standard for Arch using a wrapper script perhaps?

I'm open to adding the flags if it becomes a blocker for correct usage, and particularly if cove starts needing a configuration file or something like that.

[weebney]

Ultimately, it's your project and your call but I'm not sure what real benefit there is to breaking convention here—on both Windows and *NIX there's a standard way to store cached state that's easily available in os.UserCacheDir.