Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify ownership of rules_python #291

Closed
brandjon opened this issue Apr 14, 2020 · 10 comments · Fixed by #308
Closed

Clarify ownership of rules_python #291

brandjon opened this issue Apr 14, 2020 · 10 comments · Fixed by #308
Assignees
@brandjon
Labels
P1 type: process

Comments

@brandjon
Copy link
Member

Following up on #290, I've added @andyscott and @thundergolfer as maintainers of rules_python. We now need to define the boundaries between community-owned pieces of this repo and pieces owned by the core Bazel team.

+Cc @lberki and @laurentlb on core Bazel, and @pstradomski who is responsible for the wheel packaging rules under //experimental.

This repo currently serves two purposes: pip integration rules written purely in Starlark, and Starlark stubs for the native Python rules. Our intent is that the community take ownership of the pip integration rules (e.g., python/pip.bzl, python/wheel.bzl, packaging/..., tools/...) while core Bazel team retains ownership of the stubs (python/defs.bzl, subdirectories of python/). For repo-global things like the WORKSPACE I think the chance of stepping on each other's toes is low so I'm not worried about explicit ownership delineations there.

Action items are to spell out this division in a little more detail (expand on #290) and add CODEOWNERS. Beyond that, Andy and Jonathan should discuss how they'd like to evolve the packaging rules -- e.g. whether to merge with an existing alternative ruleset, vs preserving the existing API.
@brandjon brandjon self-assigned this Apr 14, 2020
@brandjon
Copy link
Member Author

brandjon commented Apr 14, 2020 •
edited
Loading

One minor note @andyscott and @thundergolfer: When you merge PRs affecting piptool,py and whl.py, please regenerate the par files under tools/ yourself as mentioned in CONTRIBUTING.md.

@andyscott
Copy link
Contributor

andyscott commented Apr 14, 2020 •
edited
Loading

Sounds good. Thanks for adding me.

I'm currently quite busy but should be able to make time in the next week (realistically make that two weeks!) to review/discuss.

@thundergolfer
Copy link

Thanks @brandjon, looking forward to working on this with the community. Also thanks for clarification on ownership, makes sense.

Beyond that, Andy and Jonathan should discuss how they'd like to evolve the packaging rules -- e.g. whether to merge with an existing alternative ruleset, vs preserving the existing API.

Yeah plenty to discuss here.

@abergmeier
Copy link

Following up on #290, I've added @andyscott and @thundergolfer as maintainers of rules_python.

Is there anyone with maintainer access who has time for the role? Looking at the Issues, PRs, Design Documents it seems to me like there is so far nobody visible.

@thundergolfer thundergolfer mentioned this issue Apr 21, 2020
Closed
@thundergolfer
Copy link

Hey @abergmeier,

The ball started rolling on this ownership change while Andy and I are quite busy, but expect movement soon after we've had time to do some initial orientation. We have a meeting planned for Thursday. 🙂

@abergmeier
Copy link

We have a meeting planned for Thursday

Mind if I listen?

@thundergolfer
Copy link

Much of it will be Andy and I talking about how we'll coordinate. I think it won't be appropriate to have this opened up, but anything relevant to the community will be shared. We haven't talked about how we'll do the sharing, but right now the Slack is the place of most discussion.

@andyscott
Copy link
Contributor

It's also our very first meeting, so we'll likely be spending some time to understand each other's perspective and sorting how how we'll work together to support the project!

Practically speaking, in this first call I don't expect to address specific issues/PRs open on the project. Instead, I hope we lay some groundwork for how we'll be maintaining the project going forward.

@andyscott
Copy link
Contributor

Jonathon and I just finished our call. We mostly discussed the current state of affairs with rules_python and how we can begin to maintain the rules.

Next week we are meeting again to:

  • Draft requests to the rules_python community. These are meant to foster discussion and help shape the future of the rules. We'll be posting these as Github issues.
  • Draft a rule governance doc to be committed to the repository. This will show up as a pull request or as an issue with links to a Google doc.

We'll be back again next week with another update.

@laurentlb
Copy link
Contributor

I've promoted @andyscott and @thundergolfer to admins so that they can give maintain/write roles to other people. At the same time, I've changed the role of Bazel team (~50 people) from write to triage.

There are probably other changes to do, but I'll let the new owners decide.

brandjon added a commit to brandjon/rules_python that referenced this issue May 12, 2020
@brandjon
Add documentation of community / Bazel team ownership
cb40a16 
This adds a more nuanced CODEOWNERS and explains its purpose in CONTRIBUTING.md.

Fixes bazelbuild#291.
@brandjon brandjon mentioned this issue May 12, 2020
Merged
brandjon added a commit that referenced this issue May 12, 2020
@brandjon
Add documentation of community / Bazel team ownership (#308)
4fcc24f 
This adds a more nuanced CODEOWNERS and explains its purpose in CONTRIBUTING.md.

Fixes #291.
prebeta pushed a commit to Asana/rules_python that referenced this issue Jun 2, 2020
@brandjon @prebeta
Add documentation of community / Bazel team ownership (bazelbuild#308)
c0ec9d9 
This adds a more nuanced CODEOWNERS and explains its purpose in CONTRIBUTING.md.

Fixes bazelbuild#291.
@groodt groodt mentioned this issue Jul 17, 2020
Closed
thundergolfer pushed a commit to gmweaver/rules_python that referenced this issue Jul 31, 2020
keep file permissions when unpacking
d6bbe55 
add zipextended.py to BUILD

fix import path

use pip internal unzip

use pip internal unzip tools

remove custom zipfile implementation

Add documentation of community / Bazel team ownership (bazelbuild#308)

This adds a more nuanced CODEOWNERS and explains its purpose in CONTRIBUTING.md.

Fixes bazelbuild#291.

point README readers to new 0.0.2 release (bazelbuild#302)

update version in version.bzl (bazelbuild#303)

Fix for when there are so many file arguments it creates the Command To Long error (bazelbuild#320)

Fix failing build on CI by specifying pip package version (bazelbuild#329)

`bazel build //...` was failing due to "googleapis-common-protos[grpc]"
pip package being unavailable.

It seems to be caused by latest googleapis-common-protos release.
Specify googleapis-common-protos in requirements.txt to be in the previous
version (1.51.0) to fix this.

Fixes bazelbuild#321.

"Skylark" is an outdated name of the language, please use "starlark" instead (bazelbuild#327)

Co-authored-by: Andy Scott <andyscott@users.noreply.github.com>

Support python interpreter target in pip_import. (bazelbuild#312)

* Support python interpreter target in pip_import.

This allows users to use a custom python interpreter that is built by
another repository rule instead of using a pre-built interpreter binary
that is checked-in.

This tangentially addresses bazelbuild#257 since a common setup is to use the
custom built interpreter in the python toolchain.

For example, see: https://github.com/kku1993/bazel-hermetic-python

* Actually use interpreter path.

Co-authored-by: Andy Scott <andyscott@users.noreply.github.com>

Address bazelbuild#289 (bazelbuild#328)

Co-authored-by: Andy Scott <andyscott@users.noreply.github.com>

Fix errors with incompatible_disallow_empty_glob (bazelbuild#315)

Allow py_library sources to be empty.
If --incompatible_disallow_empty_glob is set then generated py_library
targets will fail if there are no .py files.

Examples are pymssql==2.1.4 and cx-Oracle==7.2.3.

Set `allow_empty = True` for glob().

Bazel issue for incompatible_disallow_empty_glob:
bazelbuild/bazel#8195

Co-authored-by: Andy Scott <andyscott@users.noreply.github.com>

rebuild piptool and whltool

update filename, add links to pip function definitions

remove typing checks

chore: github setup improvements (bazelbuild#334)

Remove mention and usage of Bazel Federation (bazelbuild#339)

It's currently a stalled project so it's not useful for us to direct new users there in our README.
Separately it is harder to develop on rules_python since it is currently not self-contained.
For example it's hard to find or adjust the version of rules_pkg without looking/editing in the federation repo.
Tony says this is an okay change: bazelbuild/bazel-federation@63f9746#commitcomment-40577834

leaner implementation of pip unzip

remove unzip.py

temp test with tools

2nd test with tools

final test with tools

replace with master tools

merge original tools

feat(examples): move examples to a nested WORKSPACE (bazelbuild#337)

This lets users understand the example in isolation. They can copy/paste the example directory
and it works correctly.

This refactors the existing examples which are quite weak, only really demonstrating pip usage.
This makes room for examples demonstrating other features (like protocol buffers) or package
managers (like poetry).

In a later commit I'll add bazel-integration-testing so we get a test target that confirms
the examples build (including their WORKSPACE being self-contained)

warn against putting .par file changes in PR. (bazelbuild#342)
thundergolfer pushed a commit to gmweaver/rules_python that referenced this issue Jul 31, 2020
keep file permissions when unpacking
6742ef2 
add zipextended.py to BUILD

fix import path

use pip internal unzip

use pip internal unzip tools

remove custom zipfile implementation

Add documentation of community / Bazel team ownership (bazelbuild#308)

This adds a more nuanced CODEOWNERS and explains its purpose in CONTRIBUTING.md.

Fixes bazelbuild#291.

point README readers to new 0.0.2 release (bazelbuild#302)

update version in version.bzl (bazelbuild#303)

Fix for when there are so many file arguments it creates the Command To Long error (bazelbuild#320)

Fix failing build on CI by specifying pip package version (bazelbuild#329)

`bazel build //...` was failing due to "googleapis-common-protos[grpc]"
pip package being unavailable.

It seems to be caused by latest googleapis-common-protos release.
Specify googleapis-common-protos in requirements.txt to be in the previous
version (1.51.0) to fix this.

Fixes bazelbuild#321.

"Skylark" is an outdated name of the language, please use "starlark" instead (bazelbuild#327)

Co-authored-by: Andy Scott <andyscott@users.noreply.github.com>

Support python interpreter target in pip_import. (bazelbuild#312)

* Support python interpreter target in pip_import.

This allows users to use a custom python interpreter that is built by
another repository rule instead of using a pre-built interpreter binary
that is checked-in.

This tangentially addresses bazelbuild#257 since a common setup is to use the
custom built interpreter in the python toolchain.

For example, see: https://github.com/kku1993/bazel-hermetic-python

* Actually use interpreter path.

Co-authored-by: Andy Scott <andyscott@users.noreply.github.com>

Address bazelbuild#289 (bazelbuild#328)

Co-authored-by: Andy Scott <andyscott@users.noreply.github.com>

Fix errors with incompatible_disallow_empty_glob (bazelbuild#315)

Allow py_library sources to be empty.
If --incompatible_disallow_empty_glob is set then generated py_library
targets will fail if there are no .py files.

Examples are pymssql==2.1.4 and cx-Oracle==7.2.3.

Set `allow_empty = True` for glob().

Bazel issue for incompatible_disallow_empty_glob:
bazelbuild/bazel#8195

Co-authored-by: Andy Scott <andyscott@users.noreply.github.com>

rebuild piptool and whltool

update filename, add links to pip function definitions

remove typing checks

chore: github setup improvements (bazelbuild#334)

Remove mention and usage of Bazel Federation (bazelbuild#339)

It's currently a stalled project so it's not useful for us to direct new users there in our README.
Separately it is harder to develop on rules_python since it is currently not self-contained.
For example it's hard to find or adjust the version of rules_pkg without looking/editing in the federation repo.
Tony says this is an okay change: bazelbuild/bazel-federation@63f9746#commitcomment-40577834

leaner implementation of pip unzip

remove unzip.py

temp test with tools

2nd test with tools

final test with tools

replace with master tools

merge original tools

feat(examples): move examples to a nested WORKSPACE (bazelbuild#337)

This lets users understand the example in isolation. They can copy/paste the example directory
and it works correctly.

This refactors the existing examples which are quite weak, only really demonstrating pip usage.
This makes room for examples demonstrating other features (like protocol buffers) or package
managers (like poetry).

In a later commit I'll add bazel-integration-testing so we get a test target that confirms
the examples build (including their WORKSPACE being self-contained)

warn against putting .par file changes in PR. (bazelbuild#342)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@brandjon brandjon

Labels
P1 type: process
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add documentation of community / Bazel team ownership brandjon/rules_python
5 participants
@andyscott @laurentlb @brandjon @abergmeier @thundergolfer