On 27 August 2013 17:01, Paul Moore <[email protected]> wrote:
> On 27 August 2013 00:15, PJ Eby <[email protected]> wrote:
>>
>> You pounced on a tiny piece of my email to Paul, in which I mainly
>> expressed confusion about his statements about "cost". I was having
>> trouble understanding what sort of "costs" he meant, and in subsequent
>> discussion realized that it's because he and others appeared to have
>> conflated setuptools' default-version issues, with Nick's proposal for
>> handling non-default versions.
>
>
> Note that I freely admit to *having* fear, uncertainty and doubt:
>
> I feared that Nick's proposal would impact users who just wanted to use
> default versions. I was wrong, no issue, but I was concerned.
> I was uncertain as to what Nick meant by "pkg_resources compatible". This
> has now been explained, thanks, but I wasn't sure.
> I doubted that I had the full picture and I was going to investigate. Others
> provided extra information so I didn't need to do so myself, but I had
> questions that needed to be answered initially.
I think it was partly my fault, too. While I tried to emphasise that I
was only interested in copying the pkg_resources back end layout for
alternative versions in the initial post, the replies made me realise
that (prior to this thread) PJE and Jason were probably the only other
current distutils-sig participants familiar enough with setuptools and
pkg_resources to understand the distinction between that aspect, the
default version handling and the activation API (and my familiarity is
a recent thing - I only really started understanding pkg_resources
properly in the last couple of days while trying to fix a bug I
reported a while back).
While I haven't figured out how to fix the bug yet, I learned enough
to figure out how to design a next generation alternative version
mechanism that pkg_resources should be able to support, so I'm still
calling that a win :)
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
"/full/path/to/some-alt-versions-directory/CherryPy3".
Now you can say "use latest available CherryPy2" in your virtual
environment by adding a CherryPy2.pth file with a single line
containing:
/full/path/to/some-alt-versions-directory/CherryPy2
And similarly for CherryPy3.pth (but not in the same virtual
environment as CherryPy2.pth!):
/full/path/to/some-alt-versions-directory/CherryPy3
Because this actually modifies sys.path inside the environment, it
works for both imports *and* for finding distribution metadata. If you
upgrade the version of CherryPy2 or CherryPy3, all virtual
environments referencing those directories will see the upgraded
version. Anything using a version of CherryPy installed directly into
the environment will ignore it.
For those playing along at home... this is similar to how the default
version support in setuptools works. The difference is that using .pth
files to implicitly append to sys.path in a single-application virtual
environment is significantly less surprising than doing so in a shared
Python installation :)
Cheers,
Nick.
P.S. If anyone missed me mentioning why I keep picking on the CherryPy
2 vs 3 migration, it's the actual parallel installation case that we
have to deal with for beaker-project.org. Debugging some issues with
that is what forced me to start learning how the multi-version support
in pkg_resources actually works :)
--
Nick Coghlan | [email protected] | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
