Configurable working directory (original title: Configurable backend please? )

[j-refs]

Maybe edit backend.rs, add a WorkingDir entry to the enum, and implement a load_from_cwd method? Could also maybe add a cli option similar to --stack like --storage.

That also kind of leads up to having fully configurable storage directories, just a simple enum entry, and replace load_from_* with load_from_path that should be able to take homedir, cwd, any dir.

Could also just panic if not able to access/create storage file, would be reasonable behavior.

I could help with a PR if you don't mind, I'm liking your tool a lot, just really want to have the storage file in my project directory for versioning and access, and also to share lists between devices easier

Also, sorry for the god forbidden, horrible formatting in this issue post, I'm typing on my phone, will clean up when I'm home, promise!

[booniepepper]

Hey there, thanks for submitting an issue and for using Sigi!

I think by "backend" here you specifically mean a configurable directory, and keeping the current json file format on disk. This is something I planned to support already, so I'm going to take this as the nudge I needed to just do it.

There isn't much more than some breadcrumbs for documentation on this, but when I created the Backend enum, my intent was more about implementing something like SQLite3 or Redis or other kinds of storage as "backends" -- I had a kind of ambitious custom backend I was working on until I realized that Redis already did all the things I cared about. I think I need to update the name of this enum because now that we're talking about it, I'm realizing it's both too specific and too vague haha. For me a "backend" in the context of Sigi really needs to be one setting for the location, and one for the file/interchange format. I might still need to iterate on that, but I'll get there when I get there

I think your idea here is aligned with mine, that it should be a single global flag. For anyone really digging into this, I think Sigi will work best if it's ever operating in a single directory at a time. For example, Sigi supports moving an item from one stack to another, but I think it could be get into "too confusing" usage semantics to support that same kind of thing from stack A in directory X to stack B in directory Y. Or at the very least, I don't want to design all the possible permutations of storage right now -- if anyone's interested in this, let's handle it in a new issue.

Anyway... gimme a min and let's do this

[booniepepper]

96f7f91

[booniepepper]

Will be available in 3.7.1 shortly. Thanks again!