Stow feature parity

[SlyCedix]

There's a few command line options that are present in stow that are functionally absent in tuckr:

• --no/-n: Dry run the operation and output what would occur
• --dir/-d: Set the dotfile source directory to something other than the default
• --target/-t: Set the dotfile destination dir to something other than the default. A potential solution to Feature: Allow dotfiles to target root  #22 that does not require any additional group/folder idioms, though I do think being able to do it automatically based on group structure would still be useful.
• --verbose[=N]/-v: Print out descriptions of what is happening, individual file linking, for example. Multiple levels could be used to also add in debug/trace info.
• --no-folding: Described in Only symbolically link files #49

I'm open to making PRs for some of these if wanted.

[RaphGL]

Technically tuckr is an alternative not a one to one drop-in for stow so we don't necessarily have to have the same options as long as we provide a reasonable alternative to it.

I'm not entirely sure I want to add -d and -t just yet. Have you or someone else run into a situation where tuckr's default way of handling this been a problem? I also think that once we add the ^group and %variable stuff you suggested there will be even less reason to use those. If you have a certain folder that's gonna be in different places in different systems you could just change the path in the env variable.

I don't have any reservations about adding those other flags.

[SlyCedix]

I think use cases for -t are probably pretty limited with the additional folder syntax, though it does allow for a user to deploy the same group conditionally to multiple places. An example of this might be a single account deploying the dotfiles to multiple other users.

tuckr set <group> -t /home/user1
tuckr set <group> -t /home/user2

As for -d it would help immensely with making the tuckr a little less opinionated about file locations. If a user wants their dotfiles to be stored in a different location than is described the table in the readme, it is currently impossible.
I, for example, prefer to keep my dotfiles in $HOME/Projects/dotfiles as that is where I keep all of my personal git repositories. I would go as far as saying this should be something that can be configured as an env variable, TUCKR_HOME, for example, or in the database alongside #55, so that the user does not need to always specify the directory.

Perhaps a TUCKR_DEST and TUCKR_SOURCE env variable are all that are needed, instead of a flag, allowing the user to override these if there is absolutely no other way to achieve something. Then the user can call TUCKR_DEST = /home/user1 && tuckr set <group> to send the dotfiles elsewhere.

[RaphGL]

Ok, I can do that I guess. TUCKR_HOME is easily added.

If we're making a target option under the guise of "being able to deploy to different users' homes, then isn't an env variable worse than just a -t flag for that case? Since that's not really something that's supposed to be kept for longer than a single run at a time.

[SlyCedix]

Using -t is a little more annoying if you're doing multiple operations or executing a script that does tuckr operations. I for example, have an install script that executes multiple tuckr commands to install things in a certain order as needed.

With an environment variable, the script can just assume that all of the commands just execute normally, without it, the script needs to take in its own variable, check if it's empty, and optionally use the -t flag. Both implementations have value, depending on use, but I think that since it's not really the "intended" way to handle alternative directory, having it be an environment variable is fine.

[RaphGL]

I see. Yeah, the "intended" use case is to just use the program for ur own home dir and the root dir. But yeah, I can see that.

[RaphGL]

I've just added TUCKR_HOME and TUCKR_TARGET.

Here's the wiki entry on how to use it: https://github.com/RaphGL/Tuckr/wiki#overriding-the-default