On 19 August 2013 20:47, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> > 4. We may want to add a separate note that "python -m pip" will do the
> same as the "pip" command, and may be needed to self-upgrade the pip
> command
> ("python -m pip -U pip").
>
> Have we resolved the "unfortunate importability of scripts" issue?
>
Only in the sense that exe wrappers have (once again) proved to be the only
really good solution. I promise I *will* write up the discussion so we can
stop having it. But I'm not promising anything before 2018 ;-)
But while there's a technique for implementing self-replacing exes, I don't
know if anyone has actually implemented it yet (hence my reservation that
we may need to suggest python -m pip to upgrade itself).
> Does this sound reasonable? It may be obvious to everyone but me that this
> is what we're expecting - or I may even be proposing *more* than people
> expect. But I think something along the lines of an "interface over
> implementation" definition like this would be reasonable.
>
> I think this is vital to allow use to manage future changes effectively.
> I'm
> not sure exactly how the bundling implementation is supposed to work, but
> in
> my view user programs should not be able to import pip, pkg_resources,
> setuptools etc. from the bundled locations - only from site-packages if
> they
> have actually been installed there. The interface you're describing should
> be at a CLI level only.
I don't think that's anyone's current plan (and I don't actually think it's
necessary, either).
I am happy to go with a solution that provides a guaranteed command line
interface, documented in a pep and preferably also in the Python docs. That
CLI will be couched in terms of a "pip" command - any future contenders
will have to be renamed to match the contract, but I see that as an
essential aspect of "blessing" the pip command (not the project, just the
command) as the Python installer.
Under the hood, we can happily admit that *currently* the functionality is
provided by installing the pip distribution. But if you use anything
outside of the CLI in the PEP (whether it's additional pip commands or
flags to existing commands not mentioned in the PEP, or if you import pip
directly) then you accept that you rely on pip and so work to their release
management and compatibility practices, not Python's, *and* you accept that
should an alternative project be selected to replace pip, you will no
longer have access to those features unless you manually install the pip
project (assuming pip still exists at such a time, and supports installing
side by side with its successor).
Hiding the internal implementation is extra effort for little reward, if we
take the "consenting adults" view of people using undocumented details.
Paul
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
