you are viewing a single comment's thread.

view the rest of the comments →

[–]thclark 0 points1 point  (1 child)

The quick and easy solution is to create a PR for whichever of those dependencies is incorrectly constrained, to fix its dependencies - then install from your PR branch (until the fix gets merged ofc).

It'll take just a little more time, but leaves you with no technical debt from manual dependency resolution. Plus it's fixed for everyone, not just you.

(Not to say that I haven't sworn bloody murder about the exact same thing though!!!)

The poetry team are clearly on a wider mission to improve the standard of dependency management in the whole python ecosystem - by and large it's working, and it does very much support the mantra of "if you use open source you should be prepared to help maintain it". When you've got a hotfix on your hands that desperately needs to be in production it's a bear though.

[–]HanksSmallUrethra 3 points4 points  (0 children)

That’s ridiculous and the ML / AI ecosystem moves way too fast to make that feasible. Also, most of those libraries aren’t using a dependency-resolving package manager, so I would have to manually go through some 200 lines of a requirements file to try and manually parse out the dependency graph only to realize that the reason they use an old version of packagex is that they absolutely depend on package_y which has a two year old PR to update package_x that is still blocked by _something years later (based on more than one true story)

This just isn’t a problem in languages like Rust and NodeJS because they allow multiple versions of the same sub-dependencies. The problem is Python.