Re: [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  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  撰写 
>
> 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  撰写 
>
>
>
> 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  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, 
> 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

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

[Dan Ryan]

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  撰写 

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  撰写 



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  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,  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/archive%40mail-archive.com

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

[Q via Python-Dev]

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  撰写 



>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  撰写 










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

mailto: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

mailto:Python-Dev@python.org

https://mail.python.org/mailman/listinfo/python-dev

Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/dholth%40gmail.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

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

[Q via Python-Dev]

>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  撰写 



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

 mailto: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

 mailto:Python-Dev@python.org

 https://mail.python.org/mailman/listinfo/python-dev

 Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/dholth%40gmail.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

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

[Daniel Holth]

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  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, 
> 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/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
>
___
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

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

[Brett Cannon]

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, 
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/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/archive%40mail-archive.com

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

[Q via Python-Dev]

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/archive%40mail-archive.com

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

[Q via Python-Dev]

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, which makes it is

a pain to get all these dependencies met in those close source python 
distributions.



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.



See a relevant issue of a similar package 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/archive%40mail-archive.com