folks, can someone remind me which option I can play with to set

BUILD

file name pattern, can I want to take

BUILD

and ignore

BUILD.bzl

:D

https://github.com/pantsbuild/pants/blob/c0e4ae92f95e20a068e4fb5d7a1fd7e8f0871026/contrib/confluence/src/python/pants/contrib/confluence/util/confluence_util.py#L132 is this line correct…? I’m not familiar with python… but getpage looks to require 3 args…

hi guys, i’m having a bear of a time trying to get coverage working for a python repo

i’m running a test that starts a subprocess to invoke pants that then runs the target I want to measure, aka something like -

subprocess.Popen("./pants run")

depending on what options I use to set up coverage

./pants --coverage=

or

./pants — --cov=

I seem to get different errors. Mostly version mismatch on the coverage file, or

Failed to setup subprocess coverage. ... Exception: ModuleNotFoundError("No module named 'coverage'",)

, but it works fine for a case without subprocesses.

wow, now i seem to be getting

Exception: ModuleNotFoundError("No module named '__pants_backend_python_tasks_pytest_prep_coverage_plugin__'",)

@dry-analyst-73584 ^^ I think you're the coverage expert now (although this is v1 I assume)

Can you tell me what invocation you use to run pants in your test?

within the test ? I’ve tried two ways -

psutil.Popen('./pants run {target}', shell=True)

and

psutil.Popen([os.getcwd() + '/pants', 'run', '{target}'])

Hi guys! Does anyone know update on that one?

OK! after a lot of investigation, the approach to manually combine the .coverage files also isn’t fantastic, since the execution from pants is different, it requires doing some file munging to get it to work, and also doesn’t produce great results. One thing I’m looking at now is, whether it’s possible to create a new goal that runs the py, but also includes all the deps/environment of a test environment ?

@dry-analyst-73584 @happy-kitchen-89482 ^^ ?

I think this would be straightforward to add in v2

What version of pants are you currently on?

And are you using it just for python or also for other languages?

we are on 1.21.0, i’m fairly sure we just use python, but not certain

Hey all, how does pants resolve the setuptools version, and is it possible to change? We're seeing a downstream failure due to what seems like an older version of setuptools.

Specifically re: something along the lines of the bug mentioned here:

What's the easiest way to figure out what is pulling in a wrong dependency?

I have Werkzeug pinned to 0.16.x but somehow it's pulling in 1.0.0

Hi all - looks like today is "why is Pants not resolving the right version of my dep" day 🙂

To help figure these out, some more data would be helpful. Namely: What pants commands you're running, relevant info about the targets in question (what the deps are,etc.), and are you depending on pants itself as a library (e.g., because the code in question is a custom pants plugin or something)

We are working on lockfile support in the v2 python backend, which should make a lot of these problems go away

Also, which Pants version you are using is helpful

question about ipython req string in 1.25.rc0, this doesn’t seem to work .

[ipython]
version: ["ipython==5.8.0 ; python_version<'3'","ipython==7.11.1 ; python_version>='3'"]

Hi all, I’m trying to set a scalac compiler option,

-Ypartial-unification

globally in my build, but I can’t find any documentation on how to do so. Could you guys help me out?

@happy-kitchen-89482 thanks for that, I think the details were a bit sparse. We've done a bit more digging and have a specific ask. Is it possible to upgrade the version of setuptools that pants uses. Context:

pants_version: 1.24.0rc1

we're trying to run

./pants test

with a target that uses the google-auth library. There is a specific issue with the library which breaks on older versions of

setuptools

. Running a pytest after upgrading our setuptools version to

45.1.0

passes fine. When running it through pants, pants enforces

setuptools 40.6.3

. We tried to get around this by adding in

plugins: ["setuptools_scm", "setuptools==45.1.0"]

to our pants.ini, but then we get this error.

Exception caught: (pkg_resources.VersionConflict)

...

Exception message: (setuptools 40.6.3 (/root/.cache/pants/setup/bootstrap-Linux-x86_64/pants.dSeKhP/install/lib/python3.7/site-packages), Requirement.parse('setuptools==45.1.0'))

Is there a way that we can upgrade the version pants uses for setuptools on our end? And if not, is it possible to submit a PR to the pants repo which upgrades the version of setuptools pants uses behind the scenes?

Happy to provide more context or details if needed

If it helps, we've tried the following: adding this to our pants.ini:

[pex-builder-wrapper]
setuptools_version: 45.1.0

adding this to our pants.ini:

[pytest]
version: pytest>=5.2.4
pytest_plugins: +["setuptools_version==45.1.0"]

Trying both. & manually forcing a pip install of the newer setuptools version

Just to understand the context - does your target depend on Pants as a library?