Related to #6047
Installing a large number of packages with the embedded pip takes noticeably longer than using a more regular pip - I see the install stage go from ~90s to ~60s in a particular project, if I tweak poetry so that it doesn't use embedded pip. I suppose that reaching inside a wheel and executing pip from there is more expensive.
Probably there are reasons for choosing embedded pip - presumably it leaves poetry less exposed to whatever foolishness the user has managed to achieve with their own pip. And perhaps not every environment has a non-embedded pip in it.
On the other hand this is a noticeable performance penalty. As someone who doesn't habitually mess up their environment, I'd be happy for poetry to use the pip that is already in it.
Perhaps it would be reasonable to use the embedded pip only as a last resort, if no other was available?
This changed at #4011, where the implementation of run_pip() gained an embedded=True parameter.
Related to #6047
Installing a large number of packages with the embedded pip takes noticeably longer than using a more regular pip - I see the install stage go from ~90s to ~60s in a particular project, if I tweak poetry so that it doesn't use embedded pip. I suppose that reaching inside a wheel and executing pip from there is more expensive.
Probably there are reasons for choosing embedded pip - presumably it leaves poetry less exposed to whatever foolishness the user has managed to achieve with their own pip. And perhaps not every environment has a non-embedded pip in it.
On the other hand this is a noticeable performance penalty. As someone who doesn't habitually mess up their environment, I'd be happy for poetry to use the pip that is already in it.
Perhaps it would be reasonable to use the embedded pip only as a last resort, if no other was available?
This changed at #4011, where the implementation of
run_pip()gained anembedded=Trueparameter.