It definitely re-uses everything. The cache key does include the environment though for bindings (the Pants version X.Y.Z is done by a binding command). Can you please include the full trace output instead of snippets?

rust_log.txt

And, for clarity, what is the exact GHA action yaml you use - basically what is your complete

uses: pantsbuild/actions/init-pants...

block snippet?

This is not in GHA

Ok, then what is the relevant thing for me to look at?

That would be useful.

I have a minimal dockerfile:

# Install pants
COPY pants.toml /opt/build/pants.toml
ENV PANTS_PEX_CLI_VERSION="v2.1.111"
RUN curl -L -O <https://github.com/pantsbuild/pex/releases/download/$PANTS_PEX_CLI_VERSION/pex> && chmod +x ./pex

WORKDIR /opt/build
ENV SCIE_BASE="/root/.cache/nce"
RUN curl -fLO \
  <https://github.com/pantsbuild/scie-pants/releases/download/v0.5.2/scie-pants-linux-x86_64>
RUN curl -fL \
  <https://github.com/pantsbuild/scie-pants/releases/download/v0.5.2/scie-pants-linux-x86_64.sha256> \
  | sha256sum -c -
RUN chmod +x scie-pants-linux-x86_64 && mv scie-pants-linux-x86_64 /usr/local/bin/pants
ENV PANTS_SETUP_CACHE="/root/.cache/pants/setup"
ENV PANTS_PEX_CLI_URL_TEMPLATE="file:/pex"
RUN pants version

running in aws codebuild, it's in a private isolated network. Really I'd just like to understand what causes the

scie-pants

to re-download pants

Ok, the relevant binding that misses the cache is the Pants version install:

[TRACE jump::context] Installing boot binding Binding {
        target: "/root/.cache/scie/d036c571b74670fb7cccdb2ee973b51625c6419b29dd5e2e5390d6267b873904/locks/configure-b7aeeb8b50858aff30ce47276ef8773d8eb6d5815b7942c97912685abcd733e7",
        process: Process {
            env: EnvVars {
                vars: [
                    Default(
                        (
                            "PANTS_VERSION_PROMPT_SALT",
                            "",
                        ),
                    ),
                    RemoveMatching(
                        ComparableRegex(
                            PEX_.*,
                        ),
                    ),
                    Replace(
                        (
                            "PEX_PYTHON_PATH",
                            "/root/.cache/scie/cdc3a4cfddcd63b6cebdd75b14970e02d8ef0ac5be4d350e57ab5df56c19e85e/cpython-3.9.15+20221106-x86_64-unknown-linux-gnu-install_only.tar.gz/python/bin/python3.9",
                        ),
                    ),
                    Replace(
                        (
                            "PEX_ROOT",
                            "/root/.cache/scie/d036c571b74670fb7cccdb2ee973b51625c6419b29dd5e2e5390d6267b873904/bindings/pex_root",
                        ),
                    ),
                ],
            },
            exe: "/root/.cache/scie/cdc3a4cfddcd63b6cebdd75b14970e02d8ef0ac5be4d350e57ab5df56c19e85e/cpython-3.9.15+20221106-x86_64-unknown-linux-gnu-install_only.tar.gz/python/bin/python3.9",
            args: [
                "/root/.cache/scie/04c117900eb9bf6005a70e25aa2dfe83ac94d648920c65b356c79cf8efdf48dc/tools.pex",
                "configure-pants",
                "--ptex-path",
                "/root/.cache/scie/fd8ceac7b3026655b34b2c80997c18caeb7e8d64a9dd08c0340a5ced92f947d3/ptex",
                "--pants-version",
                "2.15.0",
                "--pants-sha",
                "",
                "--pants-config",
                "/codebuild/output/src246925278/src/pants.toml",
                "--github-api-bearer-token",
                "",
                "/root/.cache/scie/d036c571b74670fb7cccdb2ee973b51625c6419b29dd5e2e5390d6267b873904/bindings",
            ],
        },
    }
[DEBUG jump::atomic] The atomic file at /root/.cache/scie/fd8ceac7b3026655b34b2c80997c18caeb7e8d64a9dd08c0340a5ced92f947d3/ptex has already been established.
[DEBUG TimerFinished] installer::unpack_blob(), Elapsed=8.882µs
[DEBUG jump::atomic] The atomic file at /root/.cache/scie/04c117900eb9bf6005a70e25aa2dfe83ac94d648920c65b356c79cf8efdf48dc/tools.pex has already been established.
[DEBUG TimerFinished] installer::unpack_blob(), Elapsed=11.613µs
[DEBUG jump::atomic] The atomic directory at /root/.cache/scie/cdc3a4cfddcd63b6cebdd75b14970e02d8ef0ac5be4d350e57ab5df56c19e85e/cpython-3.9.15+20221106-x86_64-unknown-linux-gnu-install_only.tar.gz has already been established.
[DEBUG TimerFinished] installer::unpack_archive(), Elapsed=4.846µs
[DEBUG TimerFinished] Installer::install(), Elapsed=32.059µs
Failed to fetch <https://binaries.pantsbuild.org/tags/pantsbuild.pants/release_2.15.0>: [28] Timeout was reached (Failed to connect to <http://binaries.pantsbuild.org|binaries.pantsbuild.org> port 443 after 257769 ms: Couldn't connect to server)

So, as you guessed earlier, this looks likely:

"--pants-config",
"/codebuild/output/src246925278/src/pants.toml",

That is a new path and causes a cache key miss. Everything you see in that struct is fingerprinted as a whole to form the cache key.

Let me dig a bit. This would imply if I have 2 different clones of the same repo on my machine I should get a miss when I 1st run

pants

in the 1st and then run it in the 2nd.

Yeah, confirmed. That's it. So this is not actually a codebuild problem, its a scie-pants problem. When you run

pants

the behind the scenes dependency graph that is cache checked is pants -> install -> configure. Both pants and install are cache hits, but configure is not. Basically scie-jump doesn't handle short circuiting which is something, for example, the Pants rule engine does do!

I'll file an issue here shortly.

So this is not actually a codebuild problem

That's a first 😅

And, as I usually get to point out, the root problem here is me. That's my bug. But the trigger is Mac M1. The only reason the configure step is in there is to support M1 😕

There are likely two places to fix this. I'll see if I can get a "fix" out in

scie-pants

and release that. The underlying problem though is more pervasive in scie-jump and how it handles binding graphs. That may take more effort for me to figure out / fix. I'll link that issue if I file one.

Thanks for finding this @worried-painter-31382.

Thanks a lot! My team is very excited for scie-pants

Hey everyone! I hope to have more time today and this weekend to evaluate pants in more depth, but I thought I would ask a bit of advice first. Our repo is currently a monolithic django app and I want to move it to a monorepo with as little disruption as possible. To top it off, our repo structure is a bit unusual, but not that unusual for a django API. I wanted to see how people would approach adopting pants and a monorepo structure. Here is what our current structure currently looks like:

repo
├── compose
├── config
    ├── asgi.py
    └── settings
├── docker-compose.yml
├── manage.py
├── poetry.lock
├── proxy
├── pyproject.toml
├── setup.cfg
├── startup.py
├── staticfiles
└── api
    ├── accounts
    ├── authentication
    ├── celery.py
    ├── common
    ├── conftest.py
    ├── users
    └── util

Each django app under the api directory has

tests

directory for tests

Alright, I was able to work around in scie-pants: https://github.com/pantsbuild/scie-pants/pull/130 I should have a release out later today. I'll take a look now at scie-jump and see if fancier binding caching / invalidation logic can solve this problem for all scie-jump users.

Ah, yeah - no. This had to be fixed in scie-pants. The scie-jump is already doing the right thing here.

Good evening! I asked some questions a few days ago about how to use other version formats than setuptools_scm, and I got the good advice to use env(). This works fine for setting the version in python_artifact, but how can I do that for a pex binary? I tried to also generate a distribution, but that's not used for the pex file. Am I missing some configuration?

Hey Pants Team, something odd I'm trying to force Pants to use 3.9 for bootstrap but it does not seem the env vars are working

PANTS_PYTHON_BOOTSTRAP_SEARCH_PATH="[/venv/3.9/bin]" ./pants run my-goal
Bootstrapping Pants using /bin/python3.7

I also tried setting

PANTS_PYTHON_BOOTSTRAP_NAMES="[python3.9]"

but it's still picking 3.7. I'm follow the docs here https://www.pantsbuild.org/docs/reference-python-bootstrap

Hello 👋 I’m getting this error when I run

./pants test ::

in a docker container:

02:23:24.27 [ERROR] 1 Exception encountered:

  ProcessExecutionFailure: Process 'Building 17 requirements for requirements.pex from the build-support/databricks_lock.txt resolve: boto3==1.16.7, enigma-namedframes~=1.0.2, matplotlib==3.4.2, mlflow==1.20.2, numpy<1.24,>=1.20, pandas==1.2.4, plotly==5.1.0, probablepeople, protobuf==3.17.2, pyarrow==4.0.0, pyspark-test, pyspark==3.1.2, pytest, scikit-learn==0.24.1, scipy~=1.6.0, tldextract, types-setuptools' failed with exit code 1.
stdout:

stderr:
Build of BuildRequest(target=LocalInterpreter(id='usr.bin.python3.8', platform=Platform(platform='manylinux_2_27_x86_64', impl='cp', version='3.8.0', version_info=(3, 8, 0), abi='cp38'), marker_environment=MarkerEnvironment(implementation_name='cpython', implementation_version='3.8.0', os_name='posix', platform_machine='x86_64', platform_python_implementation='CPython', platform_release='5.15.49-linuxkit', platform_system='Linux', platform_version='#1 SMP Tue Sep 13 07:51:46 UTC 2022', python_full_version='3.8.0', python_version='3.8', sys_platform='linux'), interpreter=PythonInterpreter('/usr/bin/python3.8', PythonIdentity('/usr/bin/python3.8', 'cp38', 'cp38', 'manylinux_2_27_x86_64', (3, 8, 0)))), source_path='/root/.cache/pants/named_caches/pex_root/downloads/5e25ebb18756e9715f4d26848cc7e558035025da74b4fc325a0ebc05ff538e65/pyspark-3.1.2.tar.gz', fingerprint='5e25ebb18756e9715f4d26848cc7e558035025da74b4fc325a0ebc05ff538e65') produced 2 artifacts; expected 1:
0. cp38-cp38-manylinux_2_27_x86_64.3ec80d51ce26438a86c97b71d562e96e
1. pyspark-3.1.2-py2.py3-none-any.whl

It looks like there is some function that is expected to create a single artifact (likely 1 above), but winds up creating 2 artifacts in this environment. If I include the parameter

--keep-sandboxes=on_failure

, then it preserves a directory with the following files:

./__run.sh
./source_files
./.tmp
./pex
./.cache
./.cache/pex_root
./build-support
./build-support/databricks_lock.txt

__run.sh

includes this command:

/usr/bin/python3.8 ./pex --tmpdir .tmp --jobs 6 --python-path $'/databricks/python3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' --output-file requirements.pex --no-emit-warnings --python /usr/bin/python3.8 $'--sources-directory=source_files' $'boto3==1.16.7' $'enigma-namedframes~=1.0.2' $'matplotlib==3.4.2' $'mlflow==1.20.2' $'numpy<1.24,>=1.20' $'pandas==1.2.4' $'plotly==5.1.0' probablepeople $'protobuf==3.17.2' $'pyarrow==4.0.0' pyspark-test $'pyspark==3.1.2' pytest $'scikit-learn==0.24.1' $'scipy~=1.6.0' tldextract types-setuptools --lock build-support/databricks_lock.txt --no-pypi $'--index=<https://pypi.org/simple/>' $'--index=https://*****:*****@**********/pypi/pypi-local/simple' --manylinux manylinux2014 --layout packed

which outputs the

stderr

message from above. Although this fails in a docker container locally, this same command in the same docker image works in CI/CD. No one else that I work with has reported the same error and I have tried clearing all of my caches. Installing all of the dependencies listed in that command in

__run.sh

with

pip install

works.. Lastly, this all used to work for me until very recently (I think earlier this week).= Any thoughts?

Hi everyone, I wanted to share with you my new tool, linear-cli. It's designed to help me quickly create a GitHub branch by pulling the issue name from Linear, a product management app similar to Jira. I used pants fmt, lint, mypy and pex to execute the code. If you're interested in checking it out, you can find it here: https://github.com/szto/linear-cli One issue I encountered was with executing pex globally. The current method I used felt a bit clunky. If anyone has any suggestions for a better way to execute pex globally, I would greatly appreciate your input. Thanks!

It doesn't look like pants follows

-r

in requirements.txt. I ended up concatenating all the requirements file into one and telling pants to ignore the originals.

Hello 👋 I’ve hit a curious issue with unit tests, which I’ve replicated with a toy example. If you clone the repo and run

./pants test ::

then

test/test_module_b.py:module_b

will succeed, but

test/foo/modules/module_a/test_module_a.py

will fail with the error

test/foo/dpfs/module_a/test_module_a.py:1: in <module>
    from module_a.dpfs import get_domain, plus_one
E   ModuleNotFoundError: No module named 'module_a.dpfs'

This is strange because

src/bar/dpfs/module_b/__init__.py

also imports

from module_a.dpfs import plus_one

, but the test for that module passes. This also works:

$ ./pants repl test/foo/modules/module_a:module_a
Python 3.10.6 (main, Aug 11 2022, 13:49:25) [Clang 13.1.6 (clang-1316.0.21.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from module_a import get_domain, plus_one
>>>

And

./pants check ::

passes Next, if you remove the file

rm test/foo/dpfs/module_a/__init__.py

, then

./pants test ::

will pass for all files, but

./pants check ::

will fail with the error:

test/test_module.py: error: Duplicate module named "test_module" (also at "test/foo/modules/module_a/test_module.py")

In summary, it looks like when running the unit-test

test/test_module_b.py:module_b

, the file

test/foo/modules/module_a/__init__.py

will load before

src/foo/modules/module_a/dpfs/__init__.py

because the path

test/foo/dpfs

is added to the front of

sys.path

. This can be fixed by deleting

test/foo/modules/module_a/__init__.py

, but then type-checking fails because of a collision on

test_module.py

. What is the right way out of this mess? Am I starting off on the wrong foot by putting all tests under a parent test directory?

Hi team... I need some help on using pants and poetry to handle multiple Django projects

Hey friends. I'm trying to use pants to bundle a lambda function as a pex binary, following the advice in this issue about the retirement of

lambdex

. I've uploaded the pex to lambda, and the handler is invoked correctly, but it's unable to resolve

boto3

, which should be present by default in the lambda runtime. My guess is that pants' sys path magic is preventing it from resolving. Any clues?