2 ms·

> A package manager with “well designed” packages still can't define what they do, invent program logic and behavior. The solution to this is easy and widespre

> A package manager with “well designed” packages still can't define what they do, invent program logic and behavior. The solution to this is easy and widespread. Just ship scripts with the package which allow it to compile and configure itself for the host system. Apt, npm, homebrew and cargo all allow packages to do this when necessary. A well designed PyTorch package (in a well designed package manager) could contain a stub that, when installed, looks at the host system and select and locally installs the correct version of the PyTorch binary based on its environment and configuration. This should be the job of the PyTorch package. Not the job of every single downstream consumer of PyTorch to handle independently.

forrestthewoods 3y ago
> Just ship scripts with the package which allow it to compile and configure itself for the host system. Eek. That sounds awful to me. it is exceptionally complex, fragile, and error prone. The easy solution is to SHIP YOUR FUCKING DEPENDENCIES. I’m a Windows man. Which means I don’t really use an OS level packages manager. What I expect is a zip file that I can extract and double-click an exe. To be clear I’m talking about running a program as an end user. Compiling and packaging a program is a different and intrinsically more complex story. That said, I 1000% believe that build systems should exclusively use toolchains that are part of the monorepo. Build systems should never use any system installed tools. This is more complex to setup, but quite delightful and reliable once you have it.