If this is something we may want to do, I could add a test checking that we can:

1. Start a simple PyPI-like registry.
2. Publish our runfiles package there.
3. (optional) Download it from there.

If this is something we may want to do

Yes, +1 on making it work out of the box. As a user, I don't really want to care about twine. I just want it to be easy to publish to pypi.

, I could add a test checking that we can:

1. Start a simple PyPI-like registry.
2. Publish our runfiles package there.
3. (optional) Download it from there.

Is this something we could generalize? We have quite a few tests that rely on external packages having particular structures (e.g. circular deps, native deps, extra, etc). If we had a "local" pypi registry, we'd be able to more easily define and test the relevant scenarios.

Is this something we could generalize? We have quite a few tests that rely on external packages having particular structures (e.g. circular deps, native deps, extra, etc). If we had a "local" pypi registry, we'd be able to more easily define and test the relevant scenarios.

It depends on how we want the testing to be done. If we want manual tests, then starting a script to launch a server and then running a test script manually would be doable.

If we want to integrate with the rest of the tooling so that it is automatic, it may be harder, but these are some ideas:

1. We could have an integration test with a custom runner for bazel-in-bazel tests where the runner is written in python and starts a pypiserver just before running the bazel commands.
2. Local iterations could be facilitated with running the server manually.
3. We could potentially create a build action that creates the correct layout with the correct wheels made with py_wheel rule.

I am not sure I am going to pursue this academic exercise, so if anyone finds this message and is interested, feel free :)

Not sure what to do with the failing Windows tests. Any ideas?