4 ms·
> In almost all ecosystems, it is difficult to keep track of binary dependencies. When you depend on a package’s source code, this is normally recorded in your
by yjftsjthsd-h 6mo ago
> In almost all ecosystems, it is difficult to keep track of binary dependencies. When you depend on a package’s source code, this is normally recorded in your manifest file — pyproject.toml, package.json and so on. However, when you depend on a package’s precompiled binaries, this information is usually not recorded anywhere. This means that the binary dependency relationship between your project and whatever you’re depending on is hidden — so we can say that you have a phantom binary dependency.
I know it comes up every time... but nix does kinda exist to solve this problem. At least in pure mode.
- pjmlp 6mo agoNow we just have to improve its ergonomics, while supporting all existing operating systems in production.
- okanat 6mo agoI think the Conda ecosystem is the closest and has even better ergonomics than Nix. Especially with Pixi, it is a joy to use.
- pjmlp 6mo agoIf one is using Python. All these s suggestions always fall off, because they are special cases for given programming languages, or operating systems.
- okanat 6mo agoActually no. I use it to manage more and more non-Python dependencies like Protobuf compiler and LLVM tooling. I am an embedded developer and we don't use Python for the main project. It is just scripting. It doesn't get rid of everything but it does make developer environment setup so easy.
- rekado 6mo agoConda does not solve the problems of deployment and they don't have any reproducibility guarantees. That's not surprising considering how Conda binaries are built.
- okanat 6mo agoThat's why I emphasized Pixi. With Pixi you get a per-platform lockfile that guarantees installation of the exact versions. If what you want is to deploy a server or development environment, you already get it with Pixi. If you want a Windows installer with DLLs, you don't get. However it was never the reason.