Support other package ecosystems

[ibuildthecloud]

It seems core to the experience of design of devbox is the idea of creating a "virtual environment" in the style of python venv, not docker containers. Nix obviously does this very well but there are other excellent package ecosystems that support this style. I think it would be nice if devbox had native integration into other package ecosystems that support "path portability" such as brew or language native ecosystems like pip or "npm -g". For example.

{
  "packages": [
    "brew://foo",
    "npm://bar"
  ],
}

[loreto]

@ibuildthecloud Interesting idea.

A question I've been debating in this area, and I'd love to get your take on: how should devbox.json interface with files like package.json (npm) or requirements.txt (pip) used by language native ecosystems. Are you thinking that devbox.json replaces the declarations in those files? That you declare packages in both? Something else?

[ibuildthecloud]

I think it's independent. I specifically mentioned npm -g because I'm thinking of more of what you would expect as a system level package, not what your dev project needs in it's node_modules dir. So if I put npm://aws-cdk that would do basically npm -g aws-cdk in the "global node installation dir" of my devbox.

I think if my project has package.json, requirements.txt there no need for devbox to integrate with that because I'm already going to just run npm or for requirements probably do whatever to current approach to venv is these days.

Where this need became more apparent to me was specifically trying to use devbox global. It's really hard to completely replace all tooling I want with nix packages. There are some things I'd prefer to grab from npm, pip, and brew. Obviously I can just script that crap with init hooks, for the global use case, but it really won't be a portable devbox anymore because it most likely will have hard coded paths in it (brew in the default install for example) and the UX of that is just terrible.

But I see this as a general issue to because (I'm not a javascript developer so I could be completely wrong) I've seen things where in order to develop typescript the project is just expecting that npm -g typescript is install. So the CLI is available on the path, and that it's controlled by the projects package.json. Also other stuff like watchman, or other random CLIs.