add entry_point & setuptools-git, disable "create_init_files"

[lyao-77]

What is the goal of this PR?

This PR is to:

• add "entry_point" field and "setuptools-git" package for setup build.
• disable "create_init_files". The function will auto generate an init.py file for the package. However, when the package becomes a dependency in another Bazel build, the init file will actually automatically generated by Bazel with some content. This pre-existing init file will disable the behavior with Bazel and introduce some issues for import.

[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

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

Architecture

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

[lyao-77]

Hi @dmitrii-ubskii @alexjpwalker Can you take a look at this PR? Thanks!

[flyingsilverfin]

Do you mind showing some examples of how/why these changes are to be used please?

[lyao-77]

Hi @flyingsilverfin , I think the entry_point field is only a filed for setuptools. We would like to add it because when we assemble our package using setuptools directly, we use this field.

Regarding the other change, the use case is that we used this rule to assemble one of our internal python library, and then use it in another project. We met some issues during import and realized that when bazel load it's dependency, it will generate a __init__.py for each module with the following content:

"# path manipulation added by bazelbuild/rules_python to support namespace pkgs. path = import('pkgutil').extend_path(path, name) "

However, since we hardcoded an empty __init__.py in current implementation during packaging, it will interrupt how bazel works and the import won't work

[alexjpwalker]

Hi, thanks for the contribution! By way of update (and managing expectations), unfortunately we don't currently have the resources to test this code in detail and I don't have an ETA on that. Please continue to depend on your fork of bazel-distribution for the time being, apologies for the inconvenience.

[mgosk]

+1 for merging this PR into master branch. I am already using this change from PR branch.