jetify-com
Deprecate process-compose integration
What problem are you trying to solve?
This may sound a bit radical, but I think devbox could be simplified by encouraging users to use process-compose directly, instead of bundling it and wrapping its commands. Less code to maintain, less use-cases to support.
Devbox should do one thing well: provide a reproducible development environment.
What solution would you like?
drop devbox services command.
Alternatives you've considered
No response
I don't quite understand the problem here. Have you encountered any issues with the wrapper?
Devbox should do one thing well: provide a reproducible development environment
And it should also be simple and self-explanatory. You can't expect a new user to learn process-compose first in order to use features provided by devbox.
Sorry for not being clear enough. I'll try to explain better:
Focus is about saying no. But when you're deeply involved in a project, it is often difficult to see, which aspects can be removed. I'm trying to offer you that outsiders' perspective.
Here is my experience when first trying the services feature of devbox: I added a postgres service and started it using devbox services up. Then I realized it was process-compose and wondered how I can use the non-tui mode or add other custom services. This made me switch to process-compose directly.
I also see people being confused by how the services feature works, how to use features which are already supported by process-compose or how to pass command line arguments down to process-compose: https://github.com/jetify-com/devbox/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen+process-compose
To me, those are signs for an unnecessary abstraction. You could avoid a whole bunch of misunderstandings and questions by removing this abstraction and pointing to process-compose directly. It would also simplify maintainance of devbox in the long-term. process-compose is not as complex as nix and doesn't deserve to be hidden behind an abstraction. Else you will be just replicating process-compose features in devbox for little to no gain.
The process-compose docs are very good and the system is simple. Why try to hide it?
You can still provide predefined services for e.g. postgres, for example by adding a service to an existing process-compose file, generating an additional file (devbox generate ...), or just provide service snippetes to be copied into the process-compose file in your docs. That would be much simpler and adhere more to the UNIX philosophy of doing one thing well.
I like this. I've been using process-compose via devbox services and while it generally works well I find myself hitting issues like the fact that it's not up-to-date so missing 2 bug fixes I'd like to have (logs sometimes not appearing in output, and process-compose hanging while shutting down) or the current one where if you add is_strict: true to the process-compose.yml, Devbox will just exit with status 1 but no error message.
I guess there's nothing stopping me from using process-compose directly but I do still like some of the integration. Perhaps this could be moved into a generated script you could customize.
And also, there is no easy way to change the built in process-compose version, right? So maybe it makes sense to let users decide (or even to not use/install any process manager at all).
Ref: https://github.com/jetify-com/devbox/issues/2494
