proud-dentist-2284405/13/2021, 3:11 PM
big-fall-5115305/13/2021, 3:17 PM
user05/13/2021, 3:45 PM
salmon-barista-6316305/13/2021, 4:34 PM
This is when i run a
16:27:19 [ERROR] Failed to resolve compatible distributions: 1: uvicorn==0.13.3 requires click==7.* but click 8.0.0 was resolved
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
but did not see anything in there that would lead me to the problem BUILD file. Any ideas?
user05/13/2021, 4:57 PM
powerful-florist-180705/14/2021, 1:00 AM
orange-beach-7571105/14/2021, 12:35 PM
Coverage 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?
big-fall-5115305/14/2021, 3:07 PM
user05/14/2021, 4:00 PM
average-australia-8513705/14/2021, 4:15 PM
... gevent>=21.1.0 --no-binary greenlet ...
generates something like
pip-compile -o requirements.txt <http://requirements.in|requirements.in>
# this file is generated blah blah blah --no-binary greenlet ... gevent==21.1.2 ...
it will correctly build greenlet for you when i'm going through the
pip install -r requirements.txt
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?
user05/14/2021, 9:39 PM
user05/14/2021, 9:39 PM
powerful-florist-180705/15/2021, 2:55 AM
user05/15/2021, 3:55 PM
user05/15/2021, 3:56 PM
user05/15/2021, 6:01 PM
happy-kitchen-8948205/15/2021, 6:55 PM
plain-carpet-7399405/17/2021, 12:33 AM
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
that is similar to
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
requires creating a class and a custom rule and then tests that require it can't do a simple
because the custom rule wouldn't be
pants test some/thing/needing/emulator/::
- so I think I'd need to create a new target type too and then connect the rule to the target, etc.
proud-dentist-2284405/17/2021, 4:02 PM
or similar? ie for
preferable for distinguishing unit/integration tests? If
is the better option, then what is the purpose of
powerful-florist-180705/17/2021, 4:15 PM
proud-dentist-2284405/17/2021, 4:41 PM
), 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 ...])
. 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-5064105/17/2021, 4:59 PM
proud-dentist-2284405/17/2021, 7:31 PM
, and it detects a "change" and restarts the rule.
./pants test ::
user05/18/2021, 1:34 PM
plain-river-5168205/18/2021, 2:35 PM
python_library( name = 'plugin', dependencies=[ '3rdparty/python:pyhocon', ] )
calm-ambulance-6537105/18/2021, 5:34 PM
(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:
./pants test ::
We can get it to work if all requirements.txt exactly match, however when using a constraints file, this shouldn't be necessary
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.