Comms & contributor expectations?

[MikeTheGreat]

Hello!

I'm interested in helping out with this project. Nothing massive, but fiddling around with bug- and documentation-fixes, adding tests, settings up the translation strings, etc.

I'm wondering what your thoughts are on this

And - no judgement if you'd rather do this yourself. I can see setting this up as a fun personal project and sharing it with the world because "Hey, why not?", or maybe you enjoy the technical work and don't want to become a manager in your free time, or "I would, but required hours for my dayjob just ramped up", etc, etc.

If you're interested in receiving help then I'm wondering what sort of process you'd prefer we follow. Should we check with you before diving into something, so that you know the work will be done in the way you're expecting? Would you rather we just write the code & then submit a PR?

I'd love to improve Tuckr with you!

[RaphGL]

I'm open to contributions. Feel free to work on things. The only thing I don't like is when people just dump AI output at me and make me debug their work for them while they don't put any effort in.

Other than that, if u make a reasonable change and it doesn't make things harder than it should, I don't mind it.

[MikeTheGreat]

Awesome!

I probably should have been clear earlier, but the way I'm using AI is:

1. Notice something needs to be fixed
2. Read through the code, in detail, until I know why it's not working right now, and to get an idea about how I'd like to fix it
3. Ask AI to draft the code
4. Read through the AI's code in detail to make sure it works correctly (and of course try it out to confirm that it does)
5. Edit the code so it's nicer and more concise
6. Then hand it to you

So yeah - I absolutely won't be piping AI slop at you, I promise 😁

No promises on the time table but I kinda wanted to add some tests to make sure the from_stow command keeps working, so maybe I'll look at that next

[RaphGL]

Right now the from_stow command has NO tests, it's kind of why it broke in the first place :)
I haven't touched that command in forever, I eventually made it so that get_dotfiles_path failed if there's no dotfiles deployed and broke it without noticing.

But adding a test is just adding a new function at the mod tests at the bottom of the file and this one is rather simple to do.

[MikeTheGreat]

Awesome!

BTW, I'm looking at building the tests and am running into an issue where init_cmd assumes that it's only going to use the test dir when running in test mode. That's causing problems with my solution (PR for #112). That uses init_cmd to set up the main Tuckr dir, and also the temp dir - these end up being the same dir under test.

If you're going to rewrite it anyways I might just try to get the tests running and checked in, even though they won't all pass on the main branch.

I feel like adding a parameter to override the test mode, or else refactoring and making a 'raw' version that doesn't pay attention to testing (which can then be called by a version which does, to preserve the current functionality) might be good. It feels weird that code inside the core, shipping app will do something different in test mode.

I'd love to hear what you think about this, but no rush :)

[MikeTheGreat]

Also - should this thread be moved to a discussion?

[RaphGL]

The "test mode" is just a hack because cargo parallelizes unit tests, so I need to create a directory for each thread to prevent race conditions.

I think I can do an init command with some temporary_from_stow as a profile or something. This should create a .config/dotfiles_temporary_from_stow which I can then use as a temporary directory.

Also - should this thread be moved to a discussion?

Probably? I'm not too strict about this stuff, but yeah.

[RaphGL]

I'm closing this for now. You can still use this to communicate with me tho.