bootstrap

[bugabinga]

Hi!

How do you handle initial setup?
Suppose you setup a new machine:

1. Install os
2. Install git
3. Install rustup
4. Install dotr
5. Run dotr

A lot of steps, right ;)?
Any ideas how to get this down?

[lnicola]

Maybe...

1. Provide binary packages for each release
2. Implement an option to clone and link a dotfiles repository

I wanted to make a PR for 2, but I wasn't sure anyone would care.

[dpc]

Even without any special steps, binaries produced by rustc are rather static:

> ldd /home/dpc/.cargo/bin/dotr
        linux-vdso.so.1 =>  (0x00007fff2b5e0000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcb4b56c000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcb4b364000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcb4b145000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcb4af2e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcb4ab4e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fcb4bac5000)

So one could check-in dotr binary into dot files repository and run it from there, eliminating 3 and 4.

Or use NixOS, have it setup everything during installation. ;)

[lnicola]

Are you interested in a PR with git2-rs support? Not that I need it, I basically never reinstall my OS, and I try not to lose my /home anyway.

[dpc]

How would that work? The problem I had with other dot-files managers was that they conflate repository management and just doing the linking. :D . And then I have to learn just another syntax, understand where do stuff goes, what is going on, what features are available, read the documentation, etc.

For this reason, I used to use GNU Stow, but even that is too complicated.

dotr supports just two operations, link stuff, and unlink it. No long READMEs, no gotchas, no problems. And it does it using walkdir etc. so it could focus on doing it fast and correctly. (I'm not even sure about the correctness part yet, but it works well enough for my simple needs). That's why I'm reluctant to link anything.

I think it would be worthwhile to gather these two operations into a library. Let's call it dotr-lib or something new like recursive-link, and then make dotr use it. Then you can just write your own tool that does exactly what you want (with git support etc.). And dotr could use that library too. This way we can share the error-prone, and rather gnarly code of linking/unlinking recursively, and use an interface that we like best with features we personally need.

What do you think?

[lnicola]

How would that work?

I was thinking of a dotr clone URL command that's basically git clone without requiring git to be installed. Maybe dotr clone --link which does clone and link. That's totally not worth another front-end, but some people might find it useful.

[dpc]

If you're doing clone then why not push afterwards, and commit etc. and it spirals into complexity, and you have to put an arbitrary limit somewhere... Just saying. :)

If you want it, let's do a shared library. I'm sure it would be useful for many other projects too, so that would be a good way to help the ecosystem.

[lnicola]

If you're doing clone then why not push afterwards, and commit etc. and it spirals into complexity, and you have to put an arbitrary limit somewhere... Just saying. :)

Mine's at clone, I can install git for anything else :-). @bugabinga any opinion on this? There are computers (servers) where I'd like some dotfiles, but where I don't plan to modify them (or even have a private SSH key to the repository). But then again, I don't really need this feature.

If you want it, let's do a shared library. I'm sure it would be useful for many other projects too, so that would be a good way to help the ecosystem.

Sure, but last time I looked, I had some trouble understanding the linking and unlinking code 😕. clippy too complained of a cyclomatic complexity of around 40.

[dpc]

You could always download a tarball and not use git at all if you don't plan on pushing back.

Also you can just write a simple shell script to do it for you.

#!/bin/bash

# TODO: check if $1 is given

git clone $1 ~/dot
cd ~/dot
dotr link

Potentially you could put the dotr binary, dotfiles and the script into one binary etc.

Sure, but last time I looked, I had some trouble understanding the linking and unlinking code confused. clippy too complained of a cyclomatic complexity of around 40.

Yes, these function are complicated and I don't think it is possible to simplify them much if at all. These are just complicated scenarios that have to take into account a lot of corner cases to do the right thing. That's why I think it might be worth putting into separate library.

Also, I would have to write some test suite, at least for regressions, to keep the code correct.

[bugabinga]

Mine's at clone, I can install git for anything else :-). @bugabinga any opinion on this? There are computers (servers) where I'd like some dotfiles, but where I don't plan to modify them (or even have a private SSH key to the repository). But then again, I don't really need this feature.

`git` is not the only storage backend for dotfiles out there. I have friends that use `syncthing` and `NextCloud`. Some even _Dropbox_... The bootstraping problem means that it will probably always be easiest to use a shell script. Maybe there is a clever way to `cat` _dotr_ onto the script? Or have it simply be statically linked?

For this reason, I used to use GNU Stow, but even that is too complicated.

To be fair, `stow` was not meant for this. I also find it too complicated and it does funky stuff with linking folders, which has bitten me in the past.

Yes, these function are complicated as hell, and I don't think it is possible to simplify them much if at all. These just complicated scenarios that have to take into account a lot of corner cases to do the right thing. That's why I think it might be worth putting into separate library.

This is reason enough for a separate crate. I will help with unit tests if you decide to split out a lib, but I don't feel like refactoring ;). Does Rust already have a crate for virtual filesystems? Although symlink support in those is rare...