Support root targeting in tuckr push

[MaddyGuthridge]

Work in progress, don't merge yet please!

In particular, I am unsure how to get this working with Windows-style paths, where there is no single file system root.

Resolves #74

[MaddyGuthridge]

@RaphGL I'm thinking of making these functions accept a context object which provides all the required environment variables, especially if we want to implement the TUCKR_ROOT environment variable, which would make things even more complex. It would make sense to also refactor similar functions in dotfiles.rs to behave in the same way. Does this seem ok to you?

[RaphGL]

What are you planning to do?
Also isn't the alternative I suggested more flexible than TUCKR_ROOT
With that variable you would have to change this variable for each drive, but with ^c\Users\Programs x86 that would be equivalent to c:\\Users\\Programs x86. So users can make dotfiles go to different drivers all at once if that's ever necessary.

But yeah you'll probably need to change some functions in dotfiles.rs to handle this.
Also I don't have any variables in the context because dotfiles.rs has logic in it that handles how to discover where your dotfiles are located based on environment variables, custom targets and profiles.

[MaddyGuthridge]

I do plan on implementing your suggestion for root targeting on Windows, but I still think having a TUCKR_ROOT environment variable would be helpful, if only for testing purposes. It would certainly make testing far more reliable than the current if cfg!(test) logic.

[RaphGL]

There's a TUCKR_HOME which has the highest priority for determining where things will be the "root" of your dotfiles.
I did this hack because I would have to manually do the set up everywhere.

But if you somehow find a better solution, feel free to change it, if it doesn't work out we can roll back.

[MaddyGuthridge]

Checking my own understanding:

• TUCKR_HOME is the directory which Tuckr considers to be your home directory, into which it installs your dotfiles, right?
• My proposed TUCKR_ROOT would default to / (the file system root) and determine where dotfiles which target the OS root are installed.
• By using those two environment variables, you could control all aspects of where dotfiles are installed, which would make writing integration tests far easier.

[RaphGL]

Yes your assumptions are correct.

I still don't see how TUCKR_ROOT would be better than ^c. But you can go on and do that, changing between the 2 approaches should be rather easy.

[MaddyGuthridge]

To clarify, I mean TUCKR_ROOT in addition to ^c and the like

[RaphGL]

So you want to have a TUCKR_ROOT that is used by default if you don't specify a drive on windows?
How would that work on linux? since on UNIX systems there's only a single root for the file system and everything is mounted on to it

[MaddyGuthridge]

Not quite: I want a TUCKR_ROOT that specifies what Tuckr should consider to be the root of the file system on all platforms.

Detailed examples to make this more clear

• On a UNIXy system, with TUCKR_ROOT unspecified, installation paths for files which use root targeting will be joined to /. For example, ^etc/crontab would be linked to /etc/crontab.

• On a UNIXy system, with TUCKR_ROOT as /tmp/tuckr, installation paths for files which use root targeting will be joined to /tmp/tuckr. For example, ^etc/crontab would be linked to /tmp/tuckr/etc/crontab

• On a Windows system, with TUCKR_ROOT unspecified, installation paths for files which use root targeting are considered to be absolute, with their first component being the drive letter. For example, ^C/Windows/System32/ntoskernel.exe would link to C:\Windows\System32\ntoskernel.exe

• On a Windows system, with TUCKR_ROOT as C:\Somewhere\Else, installation paths for files which use root targeting are joined to C:\Somewhere\Else. For example, ^Windows/System32/ntoskernel.exe would link to C:\Somewhere\Else\Windows\System32\ntoskernel.exe

Use cases for this

• Testing: this means we can run integration tests on Tuckr outside of a VM without worrying about polluting the system with random files
• Setting up files inside of chroot gaols before chrooting into them (I know my university has a similar system when they run software engineering exams)
• Installing a configuration into a VM, container, or other OS's mapped storage without needing Tuckr to exist within that system

Does this make a little more sense now? Is it a good idea?

[RaphGL]

Yeah I got it now. I don't really know if it's a good idea tbh, I just don't personally have a use case for this so I don't really care about it.
If you can come up with genuine use cases (like the ones you listed) and you know you'll actually use it instead of just a theoretically potential use case, then go ahead. If you don't really have a use case for this, I'd say, put it off until there's an actual need for it. (pretty much every feature on tuckr is there because I needed it or because someone else couldn't come up with a way to do it with the features available)

[MaddyGuthridge]

The main thing I'd definitely use it for is writing a more-thorough test suite. Imo it's probably the best way to get tests that test the entire program including root targeting, since otherwise it would require an if cfg!(test) which imo is an indication that dependency injection should have been used.

Even if there is no publicly accessible environment variable, I'd still want it to be part of Tuckr's context struct, so that tests can provide custom values to it.

[RaphGL]

give it a shot, it doesn't hurt. we can roll back if it's not a good idea :)