search

jetify-com / devbox

Instant, easy, and predictable development environments
https://www.jetify.com/devbox/
Apache License 2.0
8.82k stars 207 forks source link

Deprecate process-compose integration #2382

Open fdietze opened 4 weeks ago

fdietze commented 4 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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.