Allow auto-creating missing parent directories when using `--target`

[thislooksfun]

Currently pointing --target to a directory that doesn't yet exist results in the error:

stow: --target value '<path>' is not a valid directory

I understand why this is happening, but it makes using stow to manage certain use-cases (like installing into ~/.config on a fresh system) require an extra mkdir step first.

It would be really nice if running stow with a --target directory would automatically mkdir -p that target if it does not exist. Or if it can't be made the default, then I'd at least like a CLI option to enable this behavior.

---

As an example, say that we have the following folder structure:

.
└── stow-root
    └── pkg1
        └── some-file

I would like to be able to run just stow pkg1 --dir stow-root --target stow-target and generate the following tree:

.
├── stow-root
│   └── pkg1
│       └── some-file
└── stow-target
    └── some-file -> ../stow-root/pkg1/some-file

Note that the target directory ./stow-target was created when it previously did not exist.

[aspiers]

Thanks for the feedback. There's an unwritten assumption that any Stow target directory is going to be long-lived, and that creating new target directories happens very rarely. If this assumption is correct then I'm not sure I see much value in adding an extra option which doesn't seem to be much easier than just running a mkdir -p command first. (I don't think it's safe for it be made the default behaviour as that would be a change in precedent and remove any defence against typos in the target directory.)

That said, maybe I am not understanding your use case, or why just doing mkdir -p first is too inconvenient? Very open to hearing counter-arguments.

[thislooksfun]

That's a totally fair take! I am currently trying to set up my dotfiles repo with the goal of having as close to 100% the config I care about as possible be fully defined in one central place, so setting up new computers is as easy as possible.

In the goal of having the process be as dead-simple as I can make it I am writing a script that I can run to set up any new computer in a single command (or at least that's the goal). This means that this script is designed to run on computers that are completely fresh out-of-the-box, and thus don't have a ~/.config directory yet (which is where I have stow --targeted to).

Now it is true that adding a mkdir -p ~/.config before running stow isn't hard, but in order to idiot-proof my setup as much as possible I have the --target configured in a .stowrc file, which means that now I have to have the same constant destination directory in two different files. That is a pattern I try to avoid if at all possible as it makes refactoring more complicated. If I (or anyone else who clones my dotfiles) want to change where the config is stowed they'd have to remember to change both places or it would fail. Having a flag I can pass to stow means I only need to define that path in one place rather than two.

I totally get that this is a niche situation, so if it doesn't fit in the scope of the project then I'll live with the mkdir -p solution. Just figured I'd ask!

---

Also while I'm here, I think another part of why I felt like something should change on stow's side rather than mine is that the currently error message if the --target directory doesn't exist is quite confusing. I just filed #126 with more details and a proposed solution.

[aspiers]

I see, thanks - that makes sense. In that case I'd welcome a PR which adds a --create-missing-target option. There are many other issues which I feel I need to treat as higher priority for my own limited stow coding time, but I will commit to reviewing a PR.

[dukecat0]

Hello, I am trying to implement this feature, and it works except for the time when user passes both --create-missing-target and --simulate. AFAIK, in simulation mode, the filesystem is not modified, so there is no way that we can create the missing target and perform further actions. Any ideas on how should we deal with it?

[aspiers]

I guess the simulation code would need to track virtual creation of that directory, similarly to how it tracks virtual creation of other directories / symlinks.