3 ms·
That's where we are as well, but yes the problems you didn't sidestep with poetry+docker are still there: the pypi fecosystem out there does not stop quantum fl
by imglorp 4y ago
That's where we are as well, but yes the problems you didn't sidestep with poetry+docker are still there: the pypi fecosystem out there does not stop quantum fluctuations just because you want it to. If you pin too much you're not getting security fixes and if you don't pin enough, you get bitten every time a tertiary dep changes that you never asked for. Oh yeah and there are now trojans upstream almost daily.
- tempest_ 4y agoYeah but that trade off is entirely separate. We trade security for speed(or "velocity" if you want to be jargon about it). I just pin everything and go through my projects every couple weeks and bump the deps (unless some really big CVE hits the news).
- gen220 4y agoDoes any FOSS package ecosystem have a good solution to this particular set of problems? I know Go has historically done something interesting with selecting the "minimum viable version number" for each dependency, but that's the only relevant idea that comes to mind. With PyPi, at least it's relatively trivial to self-host a pypi instance and self-manage dependency updates. In the Python ecosystem (vs e.g. Node), at least the total set of first+second-order dependencies for most normal projects is quite small (e.g. medium double digits to low triple digits). It doesn't feel too painful to manage that magnitude of upgrades on a monthly or quarterly basis.
- lmm 4y agoIn the JVM ecosystem you get the version your immediate dependency was built/released against, transitive dependencies are never silently upgraded (though if you want to upgrade then it's one command). IME that's a much better default; it does mean that when a security issue is found in a low-level library you get everyone doing a bunch of releases that just bump their dependencies, but the consistent behaviour is very much worth it.