4 ms·
To be fair, shared libraries have been problematic since the beginning of time. In the Python world, something wants numpy>=2.5.13, another wants numpy<=2.5.12
by dheera 1y ago
To be fair, shared libraries have been problematic since the beginning of time.
In the Python world, something wants numpy>=2.5.13, another wants numpy<=2.5.12, yet Python has still not come up with a way to just do "import numpy==2.5.13" and have it pluck exactly that version and import it.
In the C++ world, I've seen code that spits out syntax errors if you use a newer version of gcc, others that spit out syntax errors if you use an older version of gcc, apt-get overwrites the shared library you depended on with a newer version, lots of other issues. Install CUDA 11.2, it tries to uninstall CUDA 11.1, never mind that you had something linked to it, and that everything else in that ecosystem disobeys semantics and doesn't work with later minor revisions.
It's such a shitshow that it fully makes sense to bundle all your dependencies if you want to ship something that "just works".
For your customer, storage is cheaper than employee time wasted getting something to work.
- loloquwowndueo 1y agoRight but snaps don’t solve dependency hell (see content snaps which are shared library bundles).
- o11c 1y agoThat's what everybody uses `venv` for. Or `virtualenv` if you're stuck on old Python. But as a rule, `<=` dependencies mean there's either a disastrous fault with the library, or else the caller is blatantly passing all the "do not enter" signs. `!=` dependencies by contrast are meaningful just to avoid a particular bug.
- int_19h 1y agoVirtual environments don't solve the problem of two dependencies that you need having conflicting requirements.
- o11c 1y agoThat subproblem is fundamentally unfixable unless you're willing to allow incompatible objects to be passed around, which is a really bad idea. If your code does: o = foo_v1.get_obj() foo_v2.use_obj(o) then this is almost always undefined behavior, since the authors of `foo` will almost certainly not write their APIs to accept instances with different internals.
- Dylan16807 1y agoWith a more advanced system you can look at whether a package's use of foo is exposed in its API or completely internal, and then allow different isolated islands of packages to use different versions of foo.
- dheera 1y agoVenvs also suck because the user has to create and activate them. It would be nice if a foo.py file could just deal with all of that. A while ago I created this thing as a thought experiment. It likely doesn't work with more recent version of python though: https://news.ycombinator.com/item?id=24735303 https://news.ycombinator.com/item?id=24735303 It was partly in jest but I was not entirely un-serious; I think "dealing with dependencies" is quite possibly the biggest reason why Python isn't used to distribute end-user applications. It's a wonderful language but a really shitty import system. There are various attempts to make the experience better (pipx, poetry) but you still can't ship a .py file to someone, have them double click and run it. They still have to conda something, venv something, pipx something.
- yjftsjthsd-h 1y agoI think uv does what you want: https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
- deleted 1y ago[deleted]