summary: avoid using 'tensorflow' package in import logic #3515
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The logic in
tensorboard/summary/_tf/summary/__init__.py
has a routine where it searches a bunch of possible TF package names insys.modules
in order to find the v2 summary API symbols that it needs to re-export. This can have a false positive for the first package -tensorflow
itself - since depending on the build configuration, i.e. when building with--define=tf_api_version=1
, this package still contains the v1 rather than v2 API. We had attempted to guard against this issue by only usingtensorflow
whentf.__version__
was 2.x, but this check isn't sufficient because it's still possible to build 2.x TF versions with--define=tf_api_version=1
. In that case, this logic would mistakenly try to import the symbols fromtensorflow
, resulting in a bunch of deprecation warnings and not actually managing to re-export the critical symbols likecreate_file_writer()
.Rather than attempting to fix this check, we just avoid ever trying to use
tensorflow
. The other package names we try all have "v2" in the package name so I don't think the same issue can affect them; they will always contain the v2 API. This change might mean that we fall back to using_api
packages more often, but while that's ugly, we're already doing it in some of the cases depending on where within the TF API hierarchy the re-exporting logic gets first triggered, so it's not really a change from the status quo.Tested by patching this change internally and confirming it addresses the issues we were seeing; the existing pip package smoke tests should suffice for OSS.