feat: add --dev flag to watch and auto-reload sfx archive changes

[grifinas]

When --dev is passed, starts a background thread that monitors the sfx archive file for modifications and automatically re-unpacks when changes are detected. Skips checksum validation during repack to allow for content updates.

Motivation:
As a developer, i want to make JS/HTML changes without having to restart server. With this change, only build-sfx.sh needs to run for those cases.

Notes:

• No tests written, i don't know/see any on sfx.py, which is weird admittedly. if i can be pointed to how to write them i will.
• Watcher thread just runs mtime every second, I do not know of a more sane, OS agnostic approach.
• This probably does not work with python files, they're probably loaded once during initialization.
• Flag not documented very well.
• I'm bad at python, this is a certified works on my machine. Apply some scrutiny
• Ideally even running build-sfx would not be needed, it's just that this was a really quick way of doing it
• Adding new/deleting JS files requires python changes so this PR does not cover that use case

This PR complies with the DCO; https://developercertificate.org/

[9001]

I'll say I think the idea is kinda cool, but I don't think the sfx is the right place for this;

I'm keeping the sfx-loader as lean as possible, since it is the only bit of code in the file that doesn't get compressed -- and when this addition is not even useful for end-users, then I feel this should be done otherwise.

When I need to make changes "in the field" where I only have the sfx available, then my approach is as follows:

• run the sfx once
• navigate into /tmp/pe-copyparty.1000/ (or the path that the sfx prints during startup)
• cd copyparty/web and decompress the files I need to edit, for example gzip -d browser.js.gz
• restart the sfx, so it sees that the .gz has disappeared and it will use the .js instead

at this point, I no longer need to restart the sfx anymore, it is sufficient to edit the .js file and reload the browser, and eventually copy the .js out of /tmp when I'm done with it.

however, when it comes to the .html files, then yes I do need to restart the sfx after editing one of the files, because they are only loaded into jinja on startup -- but these require editing so rarely that it hasn't been a notable inconvenience to me. I think this could be handled with an inotify-watcher on /tmp/pe-copyparty.1000 which would restart the sfx as necessary, but that's just an idea

[grifinas]

I'm keeping the sfx-loader as lean as possible, since it is the only bit of code in the file that doesn't get compressed -- and when this addition is not even useful for end-users, then I feel this should be done otherwise.

Fair, bit of a weird hill to die on IMO, but ok,

When I need to make changes "in the field" where I only have the sfx available, then my approach is as follows:<...>

Yup started with that too. No git history, changes disappearing on PC restart and just a general long process were my motivations for adding this flag.

I think this could be handled with an inotify-watcher on /tmp/pe-copyparty.1000 which would restart the sfx as necessary, but that's just an idea

What makes you so sure that host machine supports inotify? Is there a python lib that supports it on all major OS'es?
Either way, Any process that relies on manually modifying the tmp dir is inherently flawed and does not solve the problem i seek to solve. Which is to modify project files and have the changes reflected.

If you don't want final sfx to bloat, would the approach that circumvents the weird behavior of extracting to tmp dir be more amenable? E.g. ./scripts/make-sfx.sh --dev creates a version of sfx that does not extract anything, instead uses local project files.
I considered going this route, but it detaches developer environment from the users.

[grifinas]

Come to think of it, you have that # skip 1 pattern, maybe i can just extend that logic so the users do not get sfx with dev option? It would uglify the source code a bit, but otherwise be inperceptible to users

[9001]

What makes you so sure that host machine supports inotify? Is there a python lib that supports it on all major OS'es?

to repeat the end of the quoted, "that was just an idea" -- you're reading too much into it :p

but if we take a step back for a bit -- if you run straight from the git-repo with python3 -m copyparty rather than using the sfx, then you get git-history right out the box, and no additional moving parts.

The only drawback of this approach is, similar to previously, needing to restart the process if html-files are edited, but no restarts are necessary for hot-reloading css/js files, which is what is generally modified anyways. Wouldn't that be a good approach, as it also entirely skips having to rebuild the sfx to see the changes?