Linux is available today (Ubuntu): github.com/docker/sbx-releases. Our webpage showing only brew and winget is on us.
For the people upthread who asked about on customization: templates (like snapshotting a running sandbox) and kits (YAML applied at creation like install steps, files, network and credential rules, or define a new agent outright) are the supported path now. It's early but take a look here: https://docs.docker.com/ai/sandboxes/customize/
On MCP, since credential handling was mentioned here: the sandbox sees one gateway endpoint, and OAuth tokens stay in the host credential store rather than in the VM. https://docs.docker.com/ai/sandboxes/mcp-gateway/
All this is early. We're looking at more based on feedback from users like running sandboxes in the background for long-horizon work and a lot more (including what you all raised in the thread here). Keep them coming.
The parent didn't go into any detail. I can. Homebrew has a history of ripping out your foundation underneath you. One day you are on Python 3.8, then next day you are on Python 3.10 and all your packages are broken. MacPorts doesn't do that.
Now, whether you should you be using the Homebrew Python is a completely different question. YMMV for other platforms managed via Homebrew.
I've traditionally used MacPorts for dev tooling and Homebrew for everything else, but with more aggressive adoption of tooling like uv an nvm I'm not sure the different really matters for me anymore.
Exactly. Same with PHP, MySQL etc…
Also they just block old versions and dont let you install them, you have to jump through a lot of hoops to use an old PHP version for example, so in no way developer friendly.
In the end I realized that Brew is a package manager for consumers, and as a professional i should’nt keep fighting it.
A lot of that is simply formula authors / application devs who don't know what they're doing (python@3.10 and other versions are a thing, and have been for quite a while now, but they're not always used and devs don't always keep track of the version they need) and people not updating their software for years (pythons are on a 5 year cycle everywhere, homebrew included: https://devguide.python.org/versions/ and https://formulae.brew.sh/formula/python@3.10 ).
Python in particular is well known to not be a stable target. For anyone. By design. If you expect long term use of a specific version of code, use a different language. It is not at all homebrew's fault that they're how many people discover that.
pyenv has been standard tooling for far longer than uv. depending on package manager supplied Python packages only makes sense if you’re running rhel or Debian or something and your application is packaged/deployed/the maintenance path uses dnf/apt. Otherwise you should always use a venv and use an out of package manager update mechanism. Like, in a broader sense, vendoring dependencies only makes sense if you’re shipping an application, not on a dev box.
That's what the GP means as well, you can use pyenv and uv to install multiple versions of Python and create envs with whichever version you want to use.
I switched to mise too for all my dev tooling. It just works so nicely for all kinds of ecosystems. I can use the same tool for Python, Node, Java, whatever and it just works.
