[BUG] FileNotFoundError jaraco/text/Lorem ipsum.txt when importing pkg_resources about setuptools HOT 7 CLOSED

@w4-donguk We upgraded Sphinx from 4.1.0 to 7.4.5. They removed the import of pkg_resources since 4.4.0.

FWIW, the Sphinx upgrade only resolved our issue by not importing pkg_resources. For other modules that really need to import pkg_resources, they would still encounter this issue with the latest setuptools with Bazel.

I'm reporting mainly to make sure the community is aware of this unexpected side-effect. I agree with @jaraco that setuptools probably shouldn't really compromise for all kind of weirdness in the downstream systems. I personally haven't really got the time to dive into Bazel to see if there could be patches on Bazel rules to get it work as folks suggested.

from setuptools.

I'd prefer to do nothing here and to use the package naturally, and rely on downstream tooling to account for patching any jaraco.text or to employ the proper fix using the latest Bazel, especially because the latest Setuptools no longer has control over which jaraco.text is used (as it will prefer a site-installed copy to its own).

Actually, that gives me another idea for a workaround - if bazel (or the tooling around it) had a way to install a patched version of jaraco.text (either without that property or with it renamed), Setuptools would use that version and not its bundled copy. One could package that up as jaraco.text-bazel-safe and install it when installing Setuptools. It's ugly, but at least it places the maintenance responsibility nearer the cause.

I'm going to close this for now, but feel free to follow-up, especially if the proposed workarounds turn out to be too onerous, and we might consider re-introducing the patch of the vendored copy.

from setuptools.

I think this should be fixed by the just released 71.0.2, can you check against that?

from setuptools.

Seeing the same issue, wasn't fixed for me in 71.0.3.

Writing down more context to save someone else time.

bazel doesn't support whitespaces in paths There's an experimental flag that reportedly can be used if you're using bazel 7.0.0 or above.

The previous workaround looks like it was removed in this PR
Specifically this commit and this other commit removed the a regex filter that was deleting the bit of code loading the Lorem ipsum.txt file in the vendored copy of jaraco.

jaraco is unlikely to rename the file.

from setuptools.

Thanks for the report and detailed analysis. And sorry for the inconvenience while Setuptools works to clean up some cruft that's accumulated.

I'd forgotten that I'd built in a patch for jaraco.text when vendorizing it. I was really happy to be rid of all that tech debt in 9234fc3, but I'd been working from the assumption that the patches were there solely to support vendorizing and not there to support other issues, so the removal of the workaround introduced in #3077 was unintentional.

As setuptools moves toward a regime that doesn't depend on vendored packages, any workarounds that apply to the vendored package will become less viable. Setuptools 71 has a preference for naturally-installed packages. What happens in a Bazel-managed environment if jaraco.text is installed naturally?

bazel doesn't support whitespaces in paths There's an experimental flag that reportedly can be used if you're using bazel 7.0.0 or above.

That's great news! I'd really like to know (a) if employing that flag fully addresses the issue, and (b) how viable it would be for users to adopt Bazel 7.

Assuming that's not a path to a long-term solution, is there another path by which setuptools and/or jaraco.text can be patched on import to the Bazel environment? I'd like for Setuptools not to have to bear the responsibility for compatibility with a downstream tool. I know at Google, which uses a similar tool, the jaraco.text was imported with a patch that renames the file to make it viable in that environment. Is there a way to do something similar for //target?

from setuptools.

I can confirm that this issue still exists in 71.0.2 and 71.0.3. We are running Bazel 6.4.0. I'm not sure about what the effort would be for upgrading, so I'm leaving it for other folks who might be impacted by this to tell.

As for my particular use case, we were able to fix by upgrading the Sphinx version, which does not import pkg_resources anymore. So, I'm no longer impacted.

from setuptools.

I can confirm that this issue still exists in 71.0.2 and 71.0.3. We are running Bazel 6.4.0. I'm not sure about what the effort would be for upgrading, so I'm leaving it for other folks who might be impacted by this to tell.

As for my particular use case, we were able to fix by upgrading the Sphinx version, which does not import pkg_resources anymore. So, I'm no longer impacted.

which version did you updated to?

from setuptools.