Can we flatten `pip._internal` into something else?

Can we flatten pip._internal into something else?

_Originally posted by @pradyunsg in https://github.com/pypa/pip/pull/8466#issuecomment-646159513_

I’m thinking of basically doing str.replace("internal.", "") on our imports:

• pip._internal.network -> pip._network
• pip._internal.cache -> pip._cache
• (you get the idea)
• pip._vendor stays as is.

It’ll make them a bit… nicer. It’ll be easier to write these imports, to read them and so on.

Before someone suggests a pip -> _pip, that transition would eat into a lot more of our churn budget and we’ll need to keep the pip package anyway, if we don’t want a repeat of #5599. (did you forget that’s a thing? Ubuntu users haven’t.)

[uranusjr]

Personally I feel this is little merit. The import names are cumbersome, but removing _internal isn’t helping much. OTOH this would break literally everything using pip internals, again. I know pip doesn’t really have an API and you’re at your own risk doing it etc, but it is still not a nice thing to do simply because pip maintainers think it looks better. (And also note that this change would not really help prevent #8466.)

[dstufft]

We used to not have any prefix at all and it caused a lot of confusion where people wouldn’t realize pip doesn’t have an api because it was following a convention that says “hey these names are public”. I don’t think we should lose some sort of prefix.

I think the _internal name is clearer and makes it far more obvious to people not to touch it. If we want imports to be nicer we could use relative imports instead.

Sent from my iPhone

On Jun 24, 2020, at 12:33 AM, Nguyễn Gia Phong [e-mail] wrote:

Generally I’d be happy if we have this. We can also move the packages without the underscore and tell people not to use any of pip’s internal libraries like we’re doing currently, because TBH because _spam looks ugly and communication is key.

GitHub’s History feature does not follow renames out-of-the-box.

Does this mean that blaming wouldn’t work on web UI and we need to follow the rename’s parent commit and blame there? I’ve just tried locally and git blame would still work though.

Another inconvenience is recursive grep/ack/rp: we’d need to filter out _vendor somehow and it’s not immediately obvious for me to do it with only ack for example (well I can just pipe it through e.g. grep -v _vendor but 😞). If possible, I suggest having a pip_vendor package instead.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.