On Jul 14, 2013, at 3:01 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 14 July 2013 16:43, Donald Stufft <donald@stufft.io> wrote:
I just want to make sure that the boundaries between the governance of Python and pip are clearly defined and the expectations on both sides are laid out and agreed upon before it happens. And I think this raises a good point about how the two projects are going to interact.

Agreed, I think the boundaries need to be clear. If something installed by default is *only* support code for a bundled application, then it should either adhere to the standard library's backwards compatibility policies (by appropriately marking private APIs as private), or else it should issue a warning when imported by any other application. Either of those options sounds good to me.

However, I consider expecting people to "just know" (or to look at documentation to determine) which provided modules are public or private without adhering to standard naming conventions or providing an explicit runtime warning to be unreasonable.

(and yes, if "pip" goes down the runtime warning path, we should probably look into providing a runtime warning for at least the "test" namespace and possibly even the "idlelib" namespace, too)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

Yea I forget to talk about the *actual* change that prompted that email when I started feeling dictated to which touched upon one of my fears in this process :)

I'm not against either renaming or emitting a warning. I was actually asking if just documenting the fact would be ok because I fear bugs from the code churn that renaming would cause :)

I think we'd need to rename things because emitting a warning is an all or nothing ordeal and we've had requests to make certain parts of the API public for Chef and other tools like it.

A question that certainly raises in my mind though is "standard library's backwards compatibility policies". What affect does this have on *actual* public API exposed from pip? Does it mean we cannot break compatibility for them until Python 4.x? That sounds very onerous for something that is installed in a way that allows easy upgrade and downgrading separately from Python to match the version requirements of someone using that library. Pip has it's own versions and develops at it's own speed.

I think it would be reasonable for the pip maintainers to be asked to declare a public API (even if that's "None") using the naming scheme or an import warning and declare a backwards compatibility policy for pip itself so that people can know what to expect from pip. I do not however, believe it is reasonable to bind pip to the same policy that CPython uses nor the same schedule. (If you weren't suggesting that I apologize).

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA