We need to come up with a better developer experience for people building pups.
At the moment, having to rebuild completely rebuild a pup when something has changed is not ideal.
Ideally, we extract the dbx pup subcommand that already exists into its own first-class citizen, maybe just called dbxpup (as we want users to be able to install this on their own development computers, pup is probably too generic?)
This would have a bunch of subcommands:
pup init: Prompts the user for a bunch of things, and then scaffolds a new pup in a directory.pup rebuild: As we probably won't hot-reload changes to manifest.json or pup.nix, we need an explicit command to rebuild the system if either of these things are changed.pup logs: Connects and tails the logs from the container running your pup.pup [action]: Where action could be stop, start, or restart.
The above commands would all work when running on the dogebox, but we need to think of remote-development too.
The easiest solution would be for the user to enable SSH (which is already possible) and then modify files directly on the Dogebox via whatever mechanism they would like.
The more complicated solution is for the pup command to authenticate with the remote Dogeboxd instance, and expose APIs for specific functionality of the above commands while on a remote host.
A pup that is loaded from a disk source should be put into developer mode, and its file contents loaded as a bind mount instead of through the /nix/store for its container contents.
DPanel should have some extra developer UI buttons added for these pups to allow for manual rebuilding etc.
We need to come up with a better developer experience for people building pups.
At the moment, having to rebuild completely rebuild a pup when something has changed is not ideal.
Ideally, we extract the
dbx pupsubcommand that already exists into its own first-class citizen, maybe just calleddbxpup(as we want users to be able to install this on their own development computers,pupis probably too generic?)This would have a bunch of subcommands:
pup init: Prompts the user for a bunch of things, and then scaffolds a new pup in a directory.pup rebuild: As we probably won't hot-reload changes tomanifest.jsonorpup.nix, we need an explicit command to rebuild the system if either of these things are changed.pup logs: Connects and tails the logs from the container running your pup.pup [action]: Where action could bestop,start, orrestart.The above commands would all work when running on the dogebox, but we need to think of remote-development too.
The easiest solution would be for the user to enable SSH (which is already possible) and then modify files directly on the Dogebox via whatever mechanism they would like.
The more complicated solution is for the
pupcommand to authenticate with the remote Dogeboxd instance, and expose APIs for specific functionality of the above commands while on a remote host.A pup that is loaded from a disk source should be put into developer mode, and its file contents loaded as a bind mount instead of through the /nix/store for its container contents.
DPanel should have some extra developer UI buttons added for these pups to allow for manual rebuilding etc.