switched kubernetes_asyncio to kubernetes_aio

[yliaog]

What type of PR is this?

/kind bug

What this PR does / why we need it:

switched kubernetes_asyncio to kubernetes_aio

Which issue(s) this PR fixes:

Fixes #2583

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[yliaog]

/assign @roycaihw

[yliaog]

@karimzakzouk could you take a look at this PR?

[mistydemeo]

Instead of installing a second top-level package, maybe it would make more sense to nest this under kubernetes? eg kubernetes.aio

[roycaihw]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: roycaihw, yliaog

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [roycaihw,yliaog]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[roycaihw]

/hold

per #2590 (comment) cc @yliaog

[yliaog]

Instead of installing a second top-level package, maybe it would make more sense to nest this under kubernetes? eg kubernetes.aio

kubernetes/ for synchronous client
client/
config/
e2e_test/
...
kubernetes_aio/ for asynchronous client
client/
config/
e2e_test/
...

the two have the same directory structure. It may be better to make them both top-level, rather than one nested inside another, which will look like this:
kubernetes/
client/
config/
e2e_test/
...
aio/
aio/client/
aio/config/
aio/e2e_test/
...

Let me add to the CHANGELOG that aio package is experimental, we may change it in future releasses if the community prefers the other approach.

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.

[yliaog]

@roycaihw @mistydemeo

please see the CHANGELOG update:

2d80404

[mistydemeo]

the two have the same directory structure. It may be better to make them both top-level, rather than one nested inside another, which will look like this:

I understand, but given that there's already been one issue from writing to a package owned by another package, it really feels like the safest solution here is to nest it under the existing package.

[yliaog]

the two have the same directory structure. It may be better to make them both top-level, rather than one nested inside another, which will look like this:

I understand, but given that there's already been one issue from writing to a package owned by another package, it really feels like the safest solution here is to nest it under the existing package.

That makes sense. Please take a look at PR: #2593

[karimzakzouk]

@yliaog Thanks for the ping

I actually agree with both of you here. @yliaog is totally right that physically putting the aio folder inside kubernetes/ in the repo would make the generator output super messy.

But I also agree with @mistydemeo that pushing a new top level kubernetes_aio package to PyPI is risky and might just cause the exact same namespace collisions we're trying to fix right now.

I pushed a working concept over in #2586.

Basically, it keeps the kubernetes_asyncio directory totally flat in the repo (so the generator stays clean), but installs under the kubernetes.aio namespace for end users.

I hooked a script into update-client-asyncio.sh that automatically swaps the absolute imports to relative imports right after generation. Then setup-release.py just uses package_dir={'kubernetes.aio': 'kubernetes_asyncio'} during the actual install.

It keeps the repo structure exactly how it is now, but solves the PyPI namespace issue. All tests are passing locally with this setup.Please have a look #2586.