proud-dentist-22844
05/13/2021, 3:11 PMbig-fall-51153
05/13/2021, 3:17 PMuser
05/13/2021, 3:45 PMsalmon-barista-63163
05/13/2021, 4:34 PM16:27:19 [ERROR] Failed to resolve compatible distributions:
1: uvicorn==0.13.3 requires click==7.* but click 8.0.0 was resolved
This is when i run a test.pytest
goal with ::
specified as the target. We have hundreds of build files so this is not easy to find where the culprit is. I know i can fix this with constraints.txt but I need to know what specific BUILD file is causing this. Is there a way to know? I tried --print-exception-stacktrace
but did not see anything in there that would lead me to the problem BUILD file. Any ideas?user
05/13/2021, 4:57 PMhappy-kitchen-89482
05/13/2021, 6:54 PMpowerful-florist-1807
05/14/2021, 1:00 AMorange-beach-75711
05/14/2021, 12:35 PMCoverage will not report on unencountered files
Coverage will only report on files encountered during the tests’ run. This means that your coverage score may be misleading; even with a score of 100%, you may have files without any tests.
This is a shortcoming of Coverage itself.https://www.pantsbuild.org/docs/python-test-goal#coverage However, it would be good to get some sense of which files are missing documentation in our monorepo. As the repo gets larger, it becomes more difficult to track where the coverage is lacking. So, my question is - Are there any known workarounds to generate coverage for files that are not covered by unit tests?
user
05/14/2021, 1:43 PMbig-fall-51153
05/14/2021, 3:07 PMuser
05/14/2021, 4:00 PMaverage-australia-85137
05/14/2021, 4:15 PM<http://requirements.in|requirements.in>
...
gevent>=21.1.0 --no-binary greenlet
...
Then:
pip-compile -o requirements.txt <http://requirements.in|requirements.in>
generates something like
# this file is generated blah blah blah
--no-binary greenlet
...
gevent==21.1.2
...
if you pip install -r requirements.txt
it will correctly build greenlet for you
when i'm going through the PythonRequirementLibrary
s that are generated for my project however I can't find anything referencing that I can't rely on the greenlet wheel
does that all make sense?user
05/14/2021, 9:39 PMuser
05/14/2021, 9:39 PMpowerful-florist-1807
05/15/2021, 2:55 AMuser
05/15/2021, 3:55 PMuser
05/15/2021, 3:56 PMuser
05/15/2021, 6:01 PMhappy-kitchen-89482
05/15/2021, 6:55 PMhappy-kitchen-89482
05/15/2021, 6:55 PMuser
05/15/2021, 7:26 PMplain-carpet-73994
05/17/2021, 12:33 AMExternalTool
and then a custom rule that uses that tool but that seems like a fair amount of work. What I was hoping for is a target
type like download_file
that is similar to ExternalTool
but I can then just use that as a dependency in tests that require the tool. That seems much easier as I'd pretty much just have to specify a URL and be done while ExternalTool
requires creating a class and a custom rule and then tests that require it can't do a simple pants test some/thing/needing/emulator/::
because the custom rule wouldn't be test
- so I think I'd need to create a new target type too and then connect the rule to the target, etc.proud-dentist-22844
05/17/2021, 4:02 PMtests
to unit-tests
or similar?
ie for python_tests()
is adjusting name=
or tags=
preferable for distinguishing unit/integration tests?
If tags=
is the better option, then what is the purpose of name=
?powerful-florist-1807
05/17/2021, 4:15 PMproud-dentist-22844
05/17/2021, 4:41 PMst2tests
), can I tell pants that python file X depends on resources Y so that pants knows when to invalidate due to resources changes?
ie I can use python_library(dependencies=[... list of resources targets ...])
within st2tests
. But then all of the python files in that directory will depend on all of the resources. How do I tell pants that only one file depends on one set of resources targets and a different file depends on a different set of resources?polite-garden-50641
05/17/2021, 4:59 PMproud-dentist-22844
05/17/2021, 7:31 PM./pants test ::
, and it detects a "change" and restarts the rule.user
05/18/2021, 1:34 PMplain-river-51682
05/18/2021, 2:35 PMpython_library(
name = 'plugin',
dependencies=[
'3rdparty/python:pyhocon',
]
)
calm-ambulance-65371
05/18/2021, 5:34 PM./pants test ::
(or other goals) where it attempts to resolve all requirements from the requirements.txt, but because some modules have common dependencies, it errors out with:
AssertionError: More than one direct requirement is satisfied by cbor2 5.3.0:
0. cbor2
1. cbor2<6.0,>=5.0.1
This should never happen since Pip fails when more than one requirement for a given project name key is supplied and applies for a given target interpreter environment.
We can get it to work if all requirements.txt exactly match, however when using a constraints file, this shouldn't be necessary