[Distutils] Multi-version import support for wheel files
p.f.moore at gmail.com
Tue Aug 27 11:15:29 CEST 2013
On 27 August 2013 10:00, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Just to scare people though... I did come up with a potentially decent
> use case for .pth files: they're actually a reasonable solution for
> sharing distributions between virtual environments in a way that works
> cross platform and on all currently used Python versions. Say you want
> to let virtual environments choose between "latest CherryPy 2" and
> "latest Cherry Py 3". Install CherryPy2 into a directory called
> "/full/path/to/some-alt-versions-directory/CherryPy2" and 3 into
> Now you can say "use latest available CherryPy2" in your virtual
> environment by adding a CherryPy2.pth file with a single line
Personally, I have no particular objection to .pth files. What I dislike is:
1. A proliferation (well, two of them if you mean setuptools :-)) of
general pth files containing multiple entries - I'd rather see the name of
the pth file match the project it refers to, as you shown here.
2. The hacks in setuptools' pth files to put things near the *start* of
sys.path. I know of no reason why this should be necessary.
3. Over-use of pth files resulting in an excessively long sys.path (less of
a problem in 3.3 where scanning sys.path is a lot faster).
The way pth files need to be on a "site" directory also causes some obscure
and annoying failure modes in setuptools-based installs at times (nothing
drastic, usually just a case of "you forgot to use
--single-version-externally-managed again", so the pth issue is a symptom
not a cause).
So it's mostly that pth files have a bad rep because of the way they have
been used in the past, rather than that they are a bad idea per se.
I actually quite like this approach - it's simple and uses Python features
that have been round for ages.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG