refactor(visibility)!: limit visibility of an internal library#1490
Conversation
This was arguably made too-visible previously and since all of the consumable symbols by the end users are re-exported via the //python:pip_bzl, we can keep everything that is in pip_install internal.
|
I have created this to start a discussion around visibility. I am OK to close |
|
Yeah, we want to make //docs private, see #1458 I made //python/pip_install:pip_repository_bzl public because, ... hm why did I do that. I think I was just trying to provide some alternative to the prior public bzl_library targets in //docs that covered pip_repository.bzl. It's very unclear to me whether pip_repository.bzl is supposed to be a publicly loadable target or not, and some of the old targets in //docs were very broad. The top of the docs, for example, says |
|
@groodt when you do a lgtm could you push the merge button? |
…-contrib#1490) This was arguably made too-visible previously and since all of the consumable symbols by the end users are re-exported via the //python:pip_bzl, we can keep everything that is in pip_install internal. This could be a breaking change for people who are depending on internal symbols or if they are using `whl_library` to create their own implementation of the `pip_repository` rule and are generating documentation internally. However, in that case they can apply a small patch to change the visibility of the `pip_repository_bzl` target.
This was arguably made too-visible previously and since all of the consumable
symbols by the end users are re-exported via the //python:pip_bzl, we can keep
everything that is in pip_install internal.
This could be a breaking change for people who are depending on internal
symbols or if they are using
whl_libraryto create their own implementationof the
pip_repositoryrule and are generating documentation internally.However, in that case they can apply a small patch to change the visibility of
the
pip_repository_bzltarget.