https://pantsbuild.org/ logo
Join Slack
Powered by
Okay I've resolved most of my dependency inference...
# general
r
Okay I've resolved most of my dependency inference issues I was having earlier but I'm still getting this one:
Copy code
from azure.cosmos.exceptions import CosmosHttpResponseError
E   ModuleNotFoundError: No module named 'azure.cosmos'
Does this have to do with the module mapping maybe? Even though I see azure.cosmos in the default mapping.
Side note, is it possible to add stuff to the global mapping in 
pants.toml
?
I'm also getting this one in a different unit test
Copy code
from gql.transport.requests import RequestsHTTPTransport
/Users/nick.dellosa/.cache/pants/named_caches/pex_root/venvs/s/8444aa37/venv/lib/python3.8/site-packages/gql/transport/requests.py:11: in <module>
    from requests_toolbelt.multipart.encoder import MultipartEncoder
E   ModuleNotFoundError: No module named 'requests_toolbelt'
w
it looks like the 
azure.cosmos
entry was added in the last two months: it might not be in the release that you are using
Side note, is it possible to add stuff to the global mapping in 
pants.toml
?
not currently, no: would need to add it to the 
python_requirements
target that provides the requirement: https://www.pantsbuild.org/docs/reference-python_requirements#codemodule_mappingcode
r
Is it possible to turn off dependency inference and just use everything in the specified resolve for unit tests? What's the advantage to having individual unit test files all sandboxed like that?
Also, yeah that is the issue, I'm using 2.15 but looks like 
azure.cosmos
wasn't in the 2.15 release yet
w
the advantage is improved cache hit rates because cache keys are smaller: if your entire repository uses the entire resolve, then it’s less beneficial
but most 
pants
users use it for monorepos, where different portions of the repo use different portions of the resolve.
r
Since we're intending to migrate from a bunch of smaller repos to a single monorepo, does it make sense to consolidate all of our 
requirements.txt
files into one then?
w
how the requirements are laid out does not affect the cache keys:
you can have one file or many.
r
The reason I ask is I'd like to have all module mappings specified in a centralized location.
Maybe I'll have a centralized requirements and also keep individual requirements files where it makes sense...
w
as long as you don’t have any duplicates, that should be fine.
you’ll get ambiguity warnings if you have duplicates
h
There are a couple of things you might want to play with:
1. You can use https://www.pantsbuild.org/docs/reference-python#run_against_entire_lockfile to run tests etc. against the entire lockfile instead of subsetting it, if you think it'll provide better performance
In both cases you're trading off cache granularity
r
Okay I've just about figured out everything I needed to but one last question: what's the right way to deal with the following:
Copy code
15:45:27.09 [WARN] Pants cannot infer owners for the following imports in the target path/to/my/test_module.py:tests:

  * pytest (line: 4)
I am relying on the pytest resolve for pytest installation.
Actually still having the same problem with one tricky dependency, 
requests-toolbelt
, which is a transitive dependency of 
gql
. I even tried adding it to my requirements/lockfile and in my BUILD file I have 
python_tests(dependencies=["3rdparty/python:globals#requests-toolbelt"])
but seems like pants still isn't inferring it correctly.
w
when a thirdparty dep is an undeclared dependency of another thirdparty dep, you can use overrides to add it explicitly (such that any time you depend on 
gql
you also get 
requests-toolbelt
): see https://www.pantsbuild.org/docs/python-third-party-dependencies#advanced-usage
🙏 1
🐐 1
r
@witty-crayon-22786 Thank you so much!! Any chance you also have any insight on the pytest warning I posted above?
h
You'll need to add 
pytest
to your "user resolve", because you're importing it. But, the next 2.16.0rc will include the ability to install the pytest tool from your "user resolve" instead of its "tool resolve", so you don't need to specify its version twice.
This is that weird thing where 
pytest
serves two roles - a tool, and a runtime library
2 Views
Open in Slack
PreviousNext
Powered by