peach-web
... are each their own binary
... and each include peach-lib as a dependency (so thats a fair amount of duplicated code and extra MB)
could imagine re-modelling this, so that there is just one binary, that gets called in different ways.
e.g.
peach web <args> (runs the rocket server, called by systemd)
peach setup <args>
peach update <args>
peach dyndns-update <args> (runs peach-dyndns-updater, called by systemd)
basically adding peach-web and peach-dyndns-updater as subcommands to what is currently peach-config (and renaming it peach). maybe there are also other ways.
however! I dont think we should do this now. I think we should focus on releasing something, using what's here. Just noting this as an idea, for one way we could go down from multiple binaries, to just one binary, that gets used in multiple ways.
using this setup, one could additionally imagine creating syntax sugar binaries, which are just 1 one line bash scripts, if desired... e.g.
peach-web (which calls peach web)
peach-config (which calls peach config)
etc. as desired. could even exactly mimic the current interfaces.
currently
- peach-dyndns-updater
- peach-config
- peach-web
... are each their own binary
... and each include peach-lib as a dependency (so thats a fair amount of duplicated code and extra MB)
could imagine re-modelling this, so that there is just one binary, that gets called in different ways.
e.g.
```
peach web <args> (runs the rocket server, called by systemd)
peach setup <args>
peach update <args>
peach dyndns-update <args> (runs peach-dyndns-updater, called by systemd)
```
basically adding peach-web and peach-dyndns-updater as subcommands to what is currently peach-config (and renaming it peach). maybe there are also other ways.
however! I dont think we should do this now. I think we should focus on releasing something, using what's here. Just noting this as an idea, for one way we could go down from multiple binaries, to just one binary, that gets used in multiple ways.
using this setup, one could additionally imagine creating syntax sugar binaries, which are just 1 one line bash scripts, if desired... e.g.
peach-web (which calls peach web)
peach-config (which calls peach config)
etc. as desired. could even exactly mimic the current interfaces.
cc @glyph
Now that we are using Rouille for peach-web, I think we could quite easily move the contents of the main() function in peach-web/src/main into a run() funciton in peach-web/src/main.rs,
then import peach-web into peach-cli as a dependency,
and then use peach-web/src/main::run() as a "web" subcommand within peach-cli
this would allow us to have peach-cli and peach-web as one binary, with minimal work, which I think would be pretty cool (right now both peach-config and peach-web and go-sbot all get installed as binaries in a yunohost install)
Copied from https://git.coopcloud.tech/PeachCloud/peach-workspace/pulls/128#issuecomment-13554
> Now that we are using Rouille for peach-web, I think we could quite easily move the contents of the main() function in peach-web/src/main into a run() funciton in peach-web/src/main.rs,
>
> then import peach-web into peach-cli as a dependency,
>
> and then use peach-web/src/main::run() as a "web" subcommand within peach-cli
>
> this would allow us to have peach-cli and peach-web as one binary, with minimal work, which I think would be pretty cool (right now both peach-config and peach-web and go-sbot all get installed as binaries in a yunohost install)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
currently
... are each their own binary
... and each include peach-lib as a dependency (so thats a fair amount of duplicated code and extra MB)
could imagine re-modelling this, so that there is just one binary, that gets called in different ways.
e.g.
basically adding peach-web and peach-dyndns-updater as subcommands to what is currently peach-config (and renaming it peach). maybe there are also other ways.
however! I dont think we should do this now. I think we should focus on releasing something, using what's here. Just noting this as an idea, for one way we could go down from multiple binaries, to just one binary, that gets used in multiple ways.
using this setup, one could additionally imagine creating syntax sugar binaries, which are just 1 one line bash scripts, if desired... e.g.
peach-web (which calls peach web)
peach-config (which calls peach config)
etc. as desired. could even exactly mimic the current interfaces.
cc @glyph
Copied from #128 (comment)