Deprecate process-compose integration

[fdietze]

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

[DerArkeN]

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.

[fdietze]

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.

[PhilT]

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.

[klutzer]

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: #2494