[Python-Dev] Feature request: Change a Dependency Package Version During Package Initiation

[Steve Holden]

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 <dan at 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: dan at danryan.co
>
> From: Q [mailto:qiang.fang at 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.fang at 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 <dholth at 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 <bcannon at 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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190520/6d32bf64/attachment.html>