upvote

points

by kibwen20 hours ago |
comments
upvoteby skeledrew19 hours ago|
next
[-]
> Python does not handle this use case very well

I solved this issue a few months ago. Created a tool that essentially allows the use of multiple envs at once, with their own versions of packages at any level.

reply
upvoteby mroche15 hours ago|
parent|
next
[-]
This sounds... not possible for the core problem of how Python handles dependency resolution during the life of an application? How are you setting things up so that the following scenario is valid?

    program
    ├── dependency_a
    │   └── dependency_c (1.0.0)
    └── dependency_b
        └── dependency_c (2.0.0)
Otherwise, you've created a magic layer hack to enable multi-version dependency chains in a mono-version dependency chain language.
reply
upvoteby yorwba12 hours ago|
parent|
[-]
Python's import system is extensible: https://docs.python.org/3/reference/import.html#import-hooks It might be possible to create a custom finder that will return 1.0.0 when running "import dependency_c" in dependency_a but 2.0.0 for the same import statement in dependency_b. You'll need to work around the module cache in sys.modules, though. And good luck trying this on a package that also hooks the import system...
reply
upvoteby arcatek14 hours ago|
parent|
prev|
[-]
Curious how you did this; I looked into that couple of months ago but even with custom hooks the Python injection points seemed to limited due to the internal resolution cache.
reply
upvoteby __mharrison__18 hours ago|
prev|
[-]
I'm curious. Do you have real world examples of when you want to do this?
reply
upvoteby gbear60517 hours ago|
parent|
next
[-]
This is Java, but recently I had a case where one library depended on a version of an Apache Commons library, and another library depended on a different version of the same Apache Commons library, and neither version worked with both libraries. In my case, I was able to upgrade one of them to a newer version so that I could use just one Apache Commons version, but I got lucky there.
reply
upvoteby deathanatos16 hours ago|
parent|
prev|
[-]
The monolith I work on has this dependency chain:

  monolith -> openai
  monolith -> langchain-openai -> openai
openai, thus, is both a direct and indirect dependency. langchain-openai recently had a vulnerability, and the patch fix is only after a major upgrade to openai. Thus, to upgrade langchain-openai here, I also need to upgrade monolith's use of openai. (From v1 to v2.)
reply