undefined | Better HN

0 pointsskeledrew3d ago0 comments

> 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.

0 comments

mroche3d ago

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.

skeledrewOP19h ago

I'll try to get around to a Show HN some time for it, but it's essentially as sibling reply states.

yorwba3d ago

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...

skeledrewOP19h ago

Yep that's pretty much how I do it, along with RPyC[0] for connection.

[0] https://rpyc.readthedocs.io/en/latest/

arcatek3d ago

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.

skeledrewOP19h ago

Its just objects accessed via RPyC[0] and exposed with import hooks. Thinking of a Show HN but there repo isn't really publish-ready.

[0] https://rpyc.readthedocs.io/en/latest/

j / k navigate · click thread line to collapse

0 comments

mroche3d ago

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.

skeledrewOP19h ago

I'll try to get around to a Show HN some time for it, but it's essentially as sibling reply states.

yorwba3d ago

skeledrewOP19h ago

Yep that's pretty much how I do it, along with RPyC[0] for connection.

[0] https://rpyc.readthedocs.io/en/latest/

arcatek3d ago

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.

skeledrewOP19h ago

Its just objects accessed via RPyC[0] and exposed with import hooks. Thinking of a Show HN but there repo isn't really publish-ready.

[0] https://rpyc.readthedocs.io/en/latest/

j / k navigate · click thread line to collapse