I suspect this discussion would be better moved to python-ideas, since it seems clear there needs to be some work on determining the exact requirements
On Sat, May 18, 2019 at 4:03 PM Dan Ryan <d...@danryan.co> wrote: > It probably makes the most sense to formally outline all of the behavioral > changes, expectations, and constraints you are asking for as Brett said > because dependency and package management are tricky and it's not clear (to > me at least) what the request is, what problem is being encountered, and > how it is proposed that it be resolved. > > First glance makes it sound a bit like the a prerequisite for this request > would be allowing multiple versions of the same package to be installed in > a given python environment to begin with, or else some runtime hacking of > paths would be necessary. I may be misunderstanding, but that's why a > formal approach for something like this might make some sense > > Dan Ryan > gh: @techalchemy // e: d...@danryan.co > > From: Q [mailto:qiang.f...@zoho.com.cn] > Sent: Friday, May 17, 2019 10:32 PM > To: Daniel Holth > Cc: Brett Cannon; Python-Dev > Subject: Re: [Python-Dev] Feature request: Change a Dependency Package > Version During Package Initiation > > Sorry, there is an error in my last post. It's corrected as: > The abaqus python distribution has libA 1.0, the external package to be > installed is LibB, which requires libA2.0, and we don't want to change > every import in LibB to be import /somewhere/libA2.0, because the source > code may have not been provided. > > > ---- 在 星期六, 2019-05-18 10:26:04 Q <qiang.f...@zoho.com.cn> 撰写 ---- > > From the viewpoint of the package user, people don't want to change every > import to "require a version at runtime". If "set up a python path in a > wrapper script" is a better strategy, can you please give an example for > the following use case: > The abaqus python distribution has libA 1.0, the external package to be > installed is LibB, which requires libA2.0, and we don't want to change > every import in LibB to be import libA 1.0, because the source code may > have not been provided. > In emacs, you can always advice a command to change its behaviour, which > makes it very user friendly, and that what all the following suggestion is > about. I have no idea at all how it could be implemented though. > https://github.com/mitsuhiko/multiversion/issues/1 > "The work around is to let 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 tonado version to be 2.2.1 then all modules in that > package will use tornado 2.2.1 when I import tornado." > > ---- 在 星期五, 2019-05-17 23:38:55 Daniel Holth <dho...@gmail.com> 撰写 ---- > > > > 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 <bcan...@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: > https://github.com/mitsuhiko/multiversion/issues/1 > > 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/steve%40holdenweb.com >
_______________________________________________ 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/archive%40mail-archive.com
