This sounds exactly like what people used to do with eggs. You could have multiple versions of a package on the path as eggs and then require a version at runtime. The approach has problems. Ruby also abandoned a strategy where random app code depends on package management code at runtime.

One better strategy is to set up a python path in a wrapper script.

On Fri, May 17, 2019, 11:27 Brett Cannon <bcannon@gmail.com> wrote:
Thanks for the idea but there are currently no plans to support such a feature. If you would like to see it then you will need to write a PEP with a proof-of-concept to demonstrate how you would expect such a feature to work.

On Fri., May 17, 2019, 07:55 Q via Python-Dev, <python-dev@python.org> wrote:
A lot of the Python code we use in production are used directly as imports in other python
distributions (such as the python comes with the finite element software Abaqus and MSC Marc), many
packages (such as matplotlib, numpy) that may have varying versioned dependencies.

I was wondering if this could be expanded to allow a version to be set within a package and have
that propagate to all modules in that package. For example in the root init.py if I set
multiversion(tornado, 2.2.1) then all modules in that package will use tornado 2.2.1 when I import
tornado.

See a relevant issue on github:

Thank you!
Qiang

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/dholth%40gmail.com