I'm getting a

No module named 'pkg_resources'

error when I include

mongomock

in my

thirdparty/python_test/requirements.txt

and depending on it from another BUILD file like so:

python_tests(
    name="tests",
    sources = ["test/test_*.py", "test/conftest.py"],
    dependencies=[":fixtures", "thirdparty/python:pymongo", "thirdparty/python_test:mongomock"]
)

The usual fix for this error from what I can see is updating setuptools... But I'm not having this error outside of Pants/Pex so not sure how to fix this in Pants. Any ideas?

You will find alot of libraries do this sort of thing. Here mongomock uses pkg_resources: https://github.com/mongomock/mongomock/blob/develop/mongomock/__version__.py#L1 But they do not declare this as an

install_requires

. You get away with this outside of Pants beacuse either by default, or by sheer dint of its popularity / use by other distributions you installed in your venv, you happen to have setuptools already.

2.7.1 but I'm happy to upgrade if it's better

Its not significantly better, its just easier to get right perhaps, the same thing is really going on under the covers.

Not currently I'm just bootstrapping Pants into our monorepo ... so it's all very early stages at the moment

OK. Last question: do you use a requirements file that's hooked up to Pants via a python_requirements BUILD target?

yeah

Ok, then like so: 1. remove mongomock from that requirements file. 2. Add in the existing BUILD file:

python_requirement_library(
    name="mongomock",
    requirements=["mongomock", "setuptools"],
)

If you slready had a version of setuptools defined in the requirements file, you'd instead do the following for 2.:

python_requirement_library(
    name="mongomock",
    requirements=["mongomock"],
    dependencies=[":setuptools"]
)

Or if you can upgrade to 2.8, it would look like: 1. Add

setuptools

to your

requirements.txt

2. Update

python_requirements

to this

python_requirements(
   overrides={"mongomock": {"dependencies": ":setuptools"}},
)

I personally like this approach because you get to still have all your deps in

requirements.txt

like before

Similar to default module mappings we should probably have a mechanism to auto-patch libraries like this that are known deficient. Its a bit titchier than default module mappings though because of the extra requirements vs dependencies approaches and because its probably much more version sensitive than module names. The module name is a brand after all, so maintainers are really unlikely to change that version to version.

Thanks folks 👍

Hey @stale-nightfall-29801, can you please take a look at these new docs? https://www.pantsbuild.org/v2.8/docs/python-third-party-dependencies#requirements-with-undeclared-dependencies I'm curious if this would have helped you this morning and if you have feedback to improve it

Hi Eric, sorry I'm in the UK so this was in the afternoon and I'd gone home by the time this came through. I'll look today, thank you.