Improve README documentation of pip_install rule [tiny] #501
Conversation
| target in the appropriate wheel repo. | ||
|
|
||
| ### Importing `pip` dependencies | ||
| ### Installing `pip` dependencies |
There was a problem hiding this comment.
"Installing" is more correct then "Importing" I think, as it matches pip install. Import is what happens in a module.
| `BUILD` files to translate a pip package name into the label of a `py_library` | ||
| Usage of the packaging rules involves two main steps. | ||
|
|
||
| 1. [Installing `pip` dependencies](#installing-pip-dependencies) |
There was a problem hiding this comment.
Change related to issue #406. Specifically #406 (comment)
| pip_install( | ||
| name = "my_deps", | ||
| requirements = "//path/to:requirements.txt", | ||
| ) | ||
| ``` | ||
|
|
||
| Note that since pip is executed at WORKSPACE-evaluation time, Bazel has no | ||
| Note that since `pip_install` is a repository rule and therefore executes pip at WORKSPACE-evaluation time, Bazel has no |
There was a problem hiding this comment.
Passive voice to active voice, and being explicit about what rule is executing pip.
| downloaded wheel files, and individual external repos for each wheel's extracted | ||
| contents. Users only need to interact with the central external repo; the wheel repos | ||
| are essentially an implementation detail. The central external repo provides a | ||
| `WORKSPACE` macro to create the wheel repos, as well as a function, `requirement()`, for use in |
There was a problem hiding this comment.
Naming the function being provided.
|
Why not remove https://github.com/bazelbuild/rules_python/blob/jonathon--improve-README-code-cmmnt-june2021/README.md#importing-pip-dependencies-with-pip_import-legacy as well? It seems like it's just a distraction |
|
@UebelAndre it's still supported in the rules so it should be documented somewhere. It is distracting but also easiest to maintain in the main README. |
Then why call it "legacy"? It sounds like something that is no longer being developed and I'd generally venture to say "deprecated" in that case. I think because there are now releases, users should be looking at the rev of the release they use for the docs they're interested in. So it's not necessary to maintain docs for something that's "legacy". |
|
@hrfuller and @alexeagle (who I think on vacation) what do you think RE @UebelAndre's suggestion? |
|
@UebelAndre I'll merge this as it progresses in the right direction, but will keep open the issue of whether |
On re-reading this part of the README, I thought the "central repo" and "knows about" wording could be improved.
🖱 Click me to preview README changes
PR Type
What kind of change does this PR introduce?
Does this PR introduce a breaking change?