Fix assemble_pip and deploy_pip

[lyao-77]

Currently there are some issues with these two rules: 'assemble_pip' and 'deploy_pip'.

assemble_pip: (1) data files are not included in "tarball" build; (2) it cannot produce "wheel" file which is a common needs for many use cases.

deploy_pip: (1) currently the deployment relies on "repository_registry" and username&password. However, we use "~/.pypirc" to config twine and we believe many other users have the same config. "pypi_profile" attr is added to enable this use case; (2) this rule will run into an error due to missing deps in requirements.txt; (3) this rule will run into an error due to that the "repo_type_key" arg in deploy.py is missing when running the script. Practically, only one of "release" and "snapshot" can be used for deployment; (4) this rule can only deploy single package ("tar.gz") which is incompatible with what we did for "assemble_pip".

This PR is to address all of the issues above.

[vaticle-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [ ] This change is trivial and does not require a code or architecture review.

Code

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.

[lyao-77]

@alexjpwalker Could you take a look at this PR?

[alexjpwalker]

Thanks for the PR!

The intent looks clear and reasonable. I'll find time to review it in the coming days.

[dmitrii-ubskii]

Also, it would be nice to have the option to not generate a wheel and only sdist.

[lyao-77]

Also, it would be nice to have the option to not generate a wheel and only sdist.

Hi @dmitrii-ubskii, I have addressed all of your comments by pushing new commits. Specifically for this comment, I find it kind of difficult to make the wheel build optional because the outputs field of assemble_pip seems static and it is not supposed to be dynamic in bazel. I think it doesn't hurt to build a .whl file in this case.

I did push a commit to make deployment optional. So although it will build both .whl and tar.gz, the user could choose if they would like to deploy either one of them or both.

[dmitrii-ubskii]

Looks good! @alexjpwalker, can you take a look?

[lyao-77]

@alexjpwalker @dmitrii-ubskii Hi I have addressed all of the new comments. Can you take a look again? Thanks!

[flyingsilverfin]

@lyao-77 Hi, please note that we've made some changes on top of your changes to bring the rule back in line with the standard architecture we've chosen for this repository: https://github.com/vaticle/bazel-distribution/pull/373

You'll still be able to use exactly the functionality you require as implemented in this PR, just with a different API.

[flyingsilverfin]

I'm actually also going to remove the universal part of the python wheel distribution - if this is something you would like, you should add it as an argument to assemble_pip. Most Python libraries these days are not Python 2 and 3 compatible, which is one of the requirements for Universal = 1: https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#wheels

[flyingsilverfin]

I'm actually also going to remove the universal part of the python wheel distribution - if this is something you would like, you should add it as an argument to assemble_pip. Most Python libraries these days are not Python 2 and 3 compatible, which is one of the requirements for Universal = 1: https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#wheels

This also means we're going to fix the assemble and deploy rules to be only compatible with Python 3.x, which is implemented in #375