Another related question: we are tying to use Pants in our Jenkins CI. In our CI, we run all unittest first, then integration test. Translate it to pants, we have something like

./pants --tag='unit_test' ::

and

./pants --tag='int_test' ::

, but i found the following in both steps.

[2022-04-21T17:10:57.265Z] 13:10:50.51 [INFO] Long running tasks:
[2022-04-21T17:10:57.265Z]   82.29s	Installing build-support/lockfile.txt for the resolve `python-default`
[2022-04-21T17:11:22.031Z] 13:11:20.54 [INFO] Long running tasks:
[2022-04-21T17:11:22.031Z]   112.32s	Installing build-support/lockfile.txt for the resolve `python-default`

I am wondering why this step needs to repeat? @hundreds-father-404

Hi team, I have a case where running some test using pants fails. But if I use

--no-process-cleanup

, then run the

__run.sh

in the cached folder. The same test passed. I am wondering if

__run.sh

always give the consistent result compared to running

./pants test

?\

From https://www.pantsbuild.org/docs/tagging-docker-images#setting-a-repository-name with example

BUILD

file...

docker_image(
    name="demo",
    repository="example/demo",
)

```$ ./pants package src/example:demo

# Will build the image: myimages.example.demo:latest```

where does 'myimages' come from?

Hi, how would one go about fixing this issue

ModuleNotFoundError: No module named 'pkg_resources'

with using flake8-bandit plugin using pants. Please see 🧵

@witty-crayon-22786 just wondering if you know anything about the question above?

Are you sure the cache is persisting between each step?

Another question, it seems bandit isn't using the config file I am using. This is how I have configured bandit using pants/flake8. Is there something I am missing?

[bandit]
config = ".bandit.yml"
args = ["--quiet"]
lockfile = "build-support/bandit.txt"

[flake8]
config = ".flake8"
extra_requirements.add = [
  "flake8-black==0.3.2",
  "flake8-bandit==3.0.0",
  "setuptools==62.1.0",
]
lockfile = "build-support/flake8.txt"

what do you mean by cache each step?

Pants stores cached results in

~/.cache/pants

by default. Is that dir persisting between the call to unit tests and integration tests?

em the unittest and integration tests are different stages in a Jenkins CI pipeline. I believe they are shared. No?

🤷‍♂️ I know nothing of Jenkins implmentation details. That's where I'd start investigating

thanks! I will take a look

Using Pants

2.10

, does

generate-lockfiles

support PEP 440 direct references?

I think the cache is there. But i still see `Installing build-support/lockfile.txt for the resolve `python-default`` multiple times across different places.

which version is this? if you can confirm that you are definitely preserving the cache, filing an issue with some more details about which commands you’re running in which sequence would be good. there are some contexts in which you might not be able to reuse a lockfile resolve: across

test

and

package

you might not be able to in some cases, for example. but between tests you always should be able to.

also: do you have multiple sets of interpreter constraints in this repository?

there are some contexts in which you might not be able to reuse a lockfile resolve: across

test

and

package

do you mind sharing some more info or example?

also: do you have multiple sets of interpreter constraints in this repository?

No

I just take more close look at our pipeline. As I mentioned that we have unittest, int test and we also have system test in addition. I dont see lockfile resolve in the system test. It seems for some reason, the int test just cannot reuse what unittest resolves.

do you mind sharing some more info or example?

there isn’t a very concise explanation, except to say that

test

runs on exactly one interpreter chosen by pants per-run (“internal”), and that interpreter is part of the cache key. whereas

package

is building a portable

PEX

file, and so it will attempt to maximize compatibility with your interpreter constraints, rather than matching exactly one.

interpreter_constraints = ["==3.9.*"]

This is what I have. i can pin it to a particular version and see.

I turned on the lsdebug model. where I can see the following from in the sys test step. But the int test are still resolving ‘python-default’ which is already done once in the unit test stage.

[2022-04-22T19:11:50.654Z] 15:11:50.52 [DEBUG] Starting: Scheduling: Building pytest.pex from pytest_default_lockfile.txt
[2022-04-22T19:11:50.654Z] 15:11:50.52 [DEBUG] Starting: Scheduling: Installing build-support/lockfile.txt for the resolve `python-default`
[2022-04-22T19:11:50.654Z] 15:11:50.52 [DEBUG] Completed: Hit: Local cache lookup: Building pytest.pex from pytest_default_lockfile.txt

Hi, I'm trying to build a lambda zip using the

python_awslambda

in my Mac but I'm getting this error when I run

./pants package appcode/api/transaction_details/src/main.py

:

pip._vendor.packaging.markers.UndefinedEnvironmentName: '*python_full_version' does not exist in evaluation environment.*

pid 81510 -> /Users/rifonseca/.cache/pants/named_caches/pex_root/venvs/44f0d229c64d262df3c9196eaa181a922a2a17cd/81d027995b16273d21e19dc7b1441abee1a3e3d1/pex --disable-pip-version-check --no-python-version-warning --exists-action a --isolated -q --cache-dir /Users/rifonseca/.cache/pants/named_caches/pex_root --log /private/var/folders/63/28d_yhnj2tn6f3xg1g_mp0lr0000gq/T/process-executionnyaMyQ/.tmp/tmp47qnomzj/pip.log download --dest /private/var/folders/63/28d_yhnj2tn6f3xg1g_mp0lr0000gq/T/process-executionnyaMyQ/.tmp/tmphaqx3pp0/cp39-cp39-linux_x86_64 --only-binary all --no-deps --requirement 3rdparty/python/default.lock --platform manylinux2014_x86_64 --platform linux_x86_64 --implementation cp --python-version 39 --abi cp39 --index-url https://pypi.org/simple/ --retries 5 --timeout 15 exited with 2 and STDERR:

Failed to resolve for platform linux_x86_64-cp-39-cp39. Resolve requires evaluation of unknown environment marker: 'python_full_version' does not exist in evaluation environment.

Reading through the docs, I found this:

Running from macOS and failing to build?

AWS Lambdas must run on Linux, so Pants tells PEX and Pip to build for Linux when resolving your third party dependencies. This means that you can only use pre-built wheels (bdists). If your project requires any source distributions (sdists) that must be built locally, PEX and pip will fail to run.

If this happens, you must either change your dependencies to only use dependencies with pre-built wheels or find a Linux environment to run

./pants package

.

Wondering how to do I tell

./pant package....

to only use pre-built wheels? I know if I was using

pip

directly, I could pass the

--only-binary=:all

flag.

Maybe dumb question – why do I see

Determine if necessary to partition MyPy input.

when running

lint

over python files? I though that mypy ran for the

check

goal only.

hi all - I'm having trouble with multiple versions of a dependency that I could use some help with. I would like to generate 2 lockfiles will all of the same dependencies except for a single package (one to include psycopg2, one to include psycopg2-binary). Following the docs I'm able to generate 2 lockfiles, but the problem is that the non-default generated 3rdparty/python/beam.lock only includes pyscopg2-binary, but I would like it to include all requirements in requirements.txt and add psycopg2-binary. The default 3rdparty/python/default.lock file is correct. Is that possible or do I need to duplicate my requirements.txt file with the 2 versions of pyscopg2? I'll include my BUILD files in the thread. Thanks!

Has anyone had success using

pytest-bdd

and generating a cucumber.json report as a result of multiple test files being executed? I'm finding since a pants session is per-file, using the

--cucumberjson

option results in pants over-writing the cucumber JSON with the latest test-file execution.

Are there any gotchas with using Pants docker support to push container images to Google Cloud Artifact Registry... particularly when using CircleCI's remote docker support? I can get Pants to build and tag the container images in the CI build, but it doesn't seem to like the push step. In particular... I think I need the result of running

gcloud auth configure-docker <http://europe-docker.pkg.dev|europe-docker.pkg.dev>

(or substitute other region) to be visible within the scope used by Pants.

Hi all. Is there any good practice for distributing "wheel" files with the pinned dependencies (similar to what Pants does with the

pex_binary

)? Currently, in our company, we do not have any

pex

registry and we publish our Python libraries/applications on an in-house PyPI registry. So, it is convenient to be able to publish our applications similar to our libraries by wheel files.

Hello everyone! Has someone successfully installed pants 2.10 on a Linux OS with ARM architecture? I’ve managed to get it set-up locally on a Macbook M1 with OSX, however in a arm64v8/debian devcontainer the bootstrap fails with the following error:

Bootstrapping Pants using /usr/bin/python3.9
Creating the virtualenv PEX.
Downloading the Pex PEX.
SHA256 fingerprint of <https://github.com/pantsbuild/pex/releases/download/v2.1.62/pex> verified.
Installing pantsbuild.pants==2.10.0 into a virtual environment at /root/.cache/pants/setup/bootstrap-Linux-aarch64/2.10.0_py39

I supposed that makes sense since Linux with ARM is not supported yet. However, as indicated here and here, I’ve tried to build from sources with both

./pants package src/python/pants:pants-packaged

and

build-support/bin/release.sh -q

but rust won’t compile some modules (tokio v1.16.1 or reqwest v0.11 with rust v1.60). Do you guys know if that might be related to versions compatibility or is it something inherent to Linux on ARM?

Hi @hundreds-father-404 @witty-crayon-22786 could you remind me where Pants put the cache for `Installing build-support/lockfile.txt for the resolve `python-default``?