user
11/22/2022, 5:01 PMquaint-telephone-89068
11/22/2022, 5:23 PMnpx is a bit weird (as is npm exec in my opinion).
It maintains its own cache and looks for local node_modules wherever it can. So, npx cowsay will ask to install 1.5.0 - but if I want to lock that to using a lockfile, I need to do npm install cowsay (generates package-lock.json) and then npx cowsay will use that local version in the node_modules.
So, lockfiles == good, but a bit of work here, unless there is an npx input to use a lockfile directly - but I just ran some tests that didn't work, nor can I find any docs on this subject right now.pantsbuild/pants
quaint-telephone-89068
11/22/2022, 5:37 PMexperimental_shell_command
-- liable to grow before it shrinks
• #17345
• #17404
• #17405
• #15493
• #17617
• #16807
pantsbuild/pantsquaint-telephone-89068
11/22/2022, 6:31 PMoutputs
field on experimental_shell_command
exports a file for use by subsequent targets. If the target is being used for an archive, this is probably not ideal.
Per this example, if you want to add the outputs to an archive that's not organised like your monorepo structure, you need to repeat the location of the BUILD
file as the src
field of a relocated_files
target.
Possible fixes:
• Add a strip_prefix
field to experimental_shell_command
, which would strip the prefix from the files in the output digest
• <PWD>
special value to `relocated_files`' src
or dest
fieldsbuild_file_dir()
clearer for relocated_files
uses
• Maybe something else?
pantsbuild/pantsquaint-telephone-89068
11/22/2022, 7:04 PM$ ./pants help PANTS_EXPORT_SYMLINK_PYTHON_VIRTUALENV
Unknown entity: PANTS_EXPORT_SYMLINK_PYTHON_VIRTUALENV
I would like it to show me the docs for [export].symlink_python_virtualenv
and for any other valid env variable.
pantsbuild/pantsuser
11/22/2022, 8:43 PMquaint-telephone-89068
11/22/2022, 9:03 PM./pants lint ::
and ./pants check ::
can take too long to run effectively as a single job in CI. You can run with --changed-since
to mitigate this, but that introduces its own overhead and you can still end up running effectively everything for certain diffs.
Describe the solution you'd like
./pants test
exposes a --shard=k/N
option to help mitigate the same problem. I think it'd make sense to add the same flag to lint
and check
(and fix
and fmt
to keep parity with lint
).
Describe alternatives you've considered
I could recreate the --shard
calculation using ./pants list
and some creative shell - I suspect it'd be messy.
pantsbuild/pantsquaint-telephone-89068
11/22/2022, 10:36 PMpython_awslambda
(very convenient, thanks!) plus a complete platform JSON that we got by running pex3 interpreter inspect --markers --tags
from within the Lambda environment. This environment uses tags up to "cp39-cp39-manylinux_2_26_x86_64"
.
When building on certain Linux systems, it seems that pants will happily include a manylinux_2_28
wheel (NB. 28 vs 26), which isn't compatible with the lambda environment. Pex thus fails at start-up:
...
pex: Unresolved requirements:
pex: - cryptography>=3.4.0; extra == "cryptography"
pex: Distributions contained within this pex:
...
pex: - cryptography-38.0.3-cp36-abi3-manylinux_2_28_x86_64.whl
...
Failed to import module 'lambdex_handler': Failed to resolve requirements from PEX environment @ /var/task.
Needed cp39-cp39-manylinux_2_26_x86_64 compatible dependencies for:
1: cryptography>=3.4.0; extra == "cryptography"
Required by:
python-jose 3.3.0
But this pex had no ProjectName(raw='cryptography', normalized='cryptography') distributions.
...
I've tried to create a reproducer in https://gist.github.com/huonw/504ef2a5d44efdc2c2df290c0ce5df16. This uses a complete platform from the Python 3.9 lambda environment, with a dependency that doesn't have any matching wheels. (Unfortunately due to https://pantsbuild.slack.com/archives/C046T6T9U/p1669150590877779, I cannot offer scripted commands that definitely reproduce it, because I cannot run pants under docker on my machine at the moment.)
The following shell snippet loads the repo, and packages the lambda and checks what is included:
git clone <https://gist.github.com/504ef2a5d44efdc2c2df290c0ce5df16.git> && cd 504ef2a5d44efdc2c2df290c0ce5df16 && ./pants package :lambda && unzip -p dist/lambda.zip PEX-INFO | jq .
The distributions
object should include a cryptography
distribution that's compatible with the complete platforms, e.g. cryptography-38.0.3-cp36-abi3-manylinux_2_24_x86_64.whl
.
1. ✅ it does on macOS
2. ✅ it does on Linux with Python version != 3.9
3. ❌ it doesn't on (some) Linux on Python version 3.9 (it uses cryptography-38.0.3-cp36-abi3-manylinux_2_28_x86_64.whl
). The specific environment is Github Actions ubuntu-latest
with actions/setup-python@v4
used with python-version: 3.9
. Complete platform in "Additional info" below.
I suspect the general behaviour here is that if the host system is close enough to the lambda environment, then
pants/src/python/pants/backend/awslambda/python/rules.py
Lines 107 to 109 in </pantsbuild/pants/commit/a21d8cb9b90289b1ef09e76283ad3fff3d35d8d0|a21d8cb>
means that the build will effectively ignore the exact complete_platform
JSON files, and use the host system's one. If the host system has newer glibc versions, this might select an incorrect wheel. In this case, the lambda complete platform is CPython 3.9, and thus running with the same Python version hits this issue.
Pants version
2.14.0
OS
Linux
Additional info
Complete platform of failing environment as reported by pex:
```
{"path": "/opt/hostedtoolcache/Python/3.9.15/x64/bin/python3.9", "compatible_tags": ["cp39-cp39-manylinux_2_31_x86_64", "cp39-cp39-manylinux_2_30_x86_64", "cp39-cp39-manylinux_2_29_x86_64", "cp39-cp39-manylinux_2_28_x86_64", "cp39-cp39-manylinux_2_27_x86_64", "cp39-cp39-manylinux_2_26_x86_64", "cp39-cp39-manylinux_2_25_x86_64", "cp39-cp39-manylinux_2_24_x86_64", "cp39-cp39-manylinux_2_23_x86_64", "cp39-cp39-manylinux_2_22_x86_64", "cp39-cp39-manylinux_2_21_x86_64", "cp39-cp39-manylinux_2_20_x86_64", "cp39-cp39-manylinux_2_19_x86_64", "cp39-cp39-manylinux_2_18_x86_64", "cp39-cp39-manylinux_2_17_x86_64", "cp39-cp39-manylinux2014_x86_64", "cp39-cp39-manylinux_2_16_x86_64", "cp39-cp39-manylinux_2_15_x86_64", "cp39-cp39-manylinux_2_14_x86_64", "cp39-cp39-manylinux_2_13_x86_64", "cp39-cp39-manylinux_2_12_x86_64", "cp39-cp39-manylinux2010_x86_64", "cp39-cp39-manylinux_2_11_x86_64", "cp39-cp39-manylinux_2_10_x86_64", "cp39-cp39-manylinux_2_9_x86_64", "cp39-cp39-manylinux_2_8_x86_64", "cp39-cp39-manylinux_2_7_x86_64", "cp39-cp39-manylinux_2_6_x86_64", "cp39-cp39-manylinux_2_5_x86_64", "cp39-cp39-manylinux1_x86_64", "cp39-cp39-linux_x86_64", "cp39-abi3-manylinux_2_31_x86_64", "cp39-abi3-manylinux_2_30_x86_64", "cp39-abi3-manylinux_2_29_x86_64", "cp39-abi3-manylinux_2_28_x86_64", "cp39-abi3-manylinux_2_27_x86_64", "cp39-abi3-manylinux_2_26_x86_64", "cp39-abi3-manylinux_2_25_x86_64", "cp39-abi3-manylinux_2_24_x86_64", "cp39-abi3-manylinux_2_23_x86_64", "cp39-abi3-manylinux_2_22_x86_64", "cp39-abi3-manylinux_2_21_x86_64", "cp39-abi3-manylinux_2_20_x86_64", "cp39-abi3-manylinux_2_19_x86_64", "cp39-abi3-manylinux_2_18_x86_64", "cp39-abi3-manylinux_2_17_x86_64", "cp39-abi3-manylinux2014_x86_64", "cp39-abi3-manylinux_2_16_x86_64", "cp39-abi3-manylinux_2_15_x86_64", "cp39-abi3-manylinux_2_14_x86_64", "cp39-abi3-manylinux_2_13_x86_64", "cp39-abi3-manylinux_2_12_x86_64", "cp39-abi3-manylinux2010_x86_64", "cp39-abi3-manylinux_2_11_x86_64", "cp39-abi3-manylinux_2_10_x86_64", "cp39-abi3-manylinux_2_9_x86_64", "cp39-abi3-manylinux_2_8_x86_64", "cp39-abi3-manylinux_2_7_x86_64", "cp39-abi3-manylinux_2_6_x86_64", "cp39-abi3-manylinux_2_5_x86_64", "cp39-abi3-manylinux1_x86_64", "cp39-abi3-linux_x86_64", "cp39-none-manylinux_2_31_x86_64", "cp39-none-manylinux_2_30_x86_64", "cp39-none-manylinux_2_29_x86_64", "cp39-none-manylinux_2_28_x86_64", "cp39-none-manylinux_2_27_x86_64", "cp39-none-manylinux_2_26_x86_64", "cp39-none-manylinux_2_25_x86_64", "cp39-none-manylinux_2_24_x86_64", "cp39-none-manylinux_2_23_x86_64", "cp39-none-manylinux_2_22_x86_64", "cp39-none-manylinux_2_21_x86_64", "cp39-none-manylinux_2_20_x86_64", "cp39-none-manylinux_2_19_x86_64", "cp39-none-manylinux_2_18_x86_64", "cp39-none-manylinux_2_17_x86_64", "cp39-none-manylinux2014_x86_64", "cp39-none-manylinux_2_16_x86_64", "cp39-none-manylinux_2_15_x86_64", "cp39-none-manylinux_2_14_x86_64", "cp39-none-manylinux_2_13_x86_64", "cp39-none-manylinux_2_12_x86_64", "cp39-none-manylinux2010_x86_64", "cp39-none-manylinux_2_11_x86_64", "cp39-none-manylinux_2_10_x86_64", "cp39-none-manylinux_2_9_x86_64", "cp39-none-manylinux_2_8_x86_64", "cp39-none-manylinux_2_7_x86_64", "cp39-none-manylinux_2_6_x86_64", "cp39-none-manylinux_2_5_x86_64", "cp39-none-manylinux1_x86_64", "cp39-none-linux_x86_64", "cp38-abi3-manylinux_2_31_x86_64", "cp38-abi3-manylinux_2_30_x86_64", "cp38-abi3-manylinux_2_29_x86_64", "cp38-abi3-manylinux_2_28_x86_64", "cp38-abi3-manylinux_2_27_x86_64", "cp38-abi3-manylinux_2_26_x86_64", "cp38-abi3-manylinux_2_25_x86_64", "cp38-abi3-manylinux_2_24_x86_64", "cp38-abi3-manylinux_2_23_x86_64", "cp38-abi3-manylinux_2_22_x86_64", "cp38-abi3-manylinux_2_21_x86_64", "cp38-abi3-manylinux_2_20_x86_64", "cp38-abi3-manylinux_2_19_x86_64", "cp38-abi3-manylinux_2_18_x86_64", "cp38-abi3-manylinux_2_17_x86_64", "cp38-abi3-manylinux2014_x86_64", "cp38-abi3-manylinux_2_16_x86_64", "cp38-abi3-manylinux_2_15_x86_64", "cp38-abi3-manylinux_2_14_x86_64", "cp38-abi3-manylinux_2_13_x86_64", "cp38-abi3-manylinux_2_12_x86_64", "cp38-abi3-manylinux2010_x86_64", "cp38-abi3-manylinux_2_11_x86_64", "cp38-abi3-manylinux_2_10_x86_64", "cp38-abi3-manylinux_2_9_x86_64", "cp38-abi3-manylinux_2_8_x86_64", "cp38-abi3-manylinux_2_7_x86_64", "cp38-abi3-manylinux_2_6_x86_64", "cp38-abi3-manylinux_2_5_x86_64", "cp38-abi3-manylinux1_x86_64", "cp38-abi3-linux_x86_64", "cp37-abi3-manylinux_2_31_x86_64", "cp37-abi3-manylinux_2_30_x86_64", "cp37-abi3-manylinux_2_29_x86_64", "cp37-abi3-manylinux_2_28_x86_64", "cp37-abi3-manylinux_2_27_x86_64", "cp37-abi3-manylinux_2_26_x86_…
pantsbuild/pantsquaint-telephone-89068
11/22/2022, 10:56 PMuname -ms
# Darwin arm64
docker pull --platform linux/amd64 python@sha256:c1613835d7be322f98603f356b9e0c9d40f9589e94dc9f710e714a807a665700 # 3.9 at the time of writing
# ...
docker run -t --platform linux/amd64 python@sha256:c1613835d7be322f98603f356b9e0c9d40f9589e94dc9f710e714a807a665700 bash -c 'echo -e "[GLOBAL]\npants_version = \"2.14.0\"" > pants.toml && curl -L -O <https://static.pantsbuild.org/setup/pants> && chmod +x ./pants && ./pants -ldebug --no-pantsd --no-watch-filesystem version'
# ...
# Bootstrapping Pants using /usr/local/bin/python3.9
# ...
# New virtual environment successfully created at /root/.cache/pants/setup/bootstrap-Linux-x86_64/2.14.0_py39.
# 22:53:01.00 [DEBUG] File handle limit is: 1048576
# 22:53:03.05 [DEBUG] Using [cache::CommandRunner { inner: bounded::CommandRunner { inner: nailgun::CommandRunner { inner: local::CommandRunner { .. }, .. }, .. }, .. }, cache::CommandRunner { inner: bounded::CommandRunner { inner: nailgun::CommandRunner { inner: local::CommandRunner { .. }, .. }, .. }, .. }] for process execution.
# 22:53:04.12 [DEBUG] Launching 1 roots (poll=false).
# 22:53:04.26 [DEBUG] computed 1 nodes in 0.136536 seconds. there are 7 total nodes.
# 22:53:04.51 [DEBUG] File handle limit is: 1048576
# 22:53:06.61 [DEBUG] Using [cache::CommandRunner { inner: bounded::CommandRunner { inner: nailgun::CommandRunner { inner: local::CommandRunner { .. }, .. }, .. }, .. }, cache::CommandRunner { inner: bounded::CommandRunner { inner: nailgun::CommandRunner { inner: local::CommandRunner { .. }, .. }, .. }, .. }] for process execution.
# 22:53:06.83 [DEBUG] specs are: Specs(includes=RawSpecs(description_of_origin='CLI arguments', address_literals=(), file_literals=(), file_globs=(), dir_literals=(), dir_globs=(), recursive_globs=(), ancestor_globs=(), unmatched_glob_behavior=<GlobMatchErrorBehavior.error: 'error'>, filter_by_global_options=True, from_change_detection=False), ignores=RawSpecs(description_of_origin='CLI arguments', address_literals=(), file_literals=(), file_globs=(), dir_literals=(), dir_globs=(), recursive_globs=(), ancestor_globs=(), unmatched_glob_behavior=<GlobMatchErrorBehavior.error: 'error'>, filter_by_global_options=False, from_change_detection=False))
# 22:53:06.83 [DEBUG] changed_options are: ChangedOptions(since=None, diffspec=None, dependees=<DependeesOption.NONE: 'none'>)
# 22:53:06.83 [DEBUG] Launching 1 roots (poll=false).
# 22:53:06.85 [WARN] Please either set `enabled = true` in the [anonymous-telemetry] section of pants.toml to enable sending anonymous stats to the Pants project to aid development, or set `enabled = false` to disable it. No telemetry sent for this run. An explicit setting will get rid of this message. See <https://www.pantsbuild.org/v2.14/docs/anonymous-telemetry> for details.
# 22:53:06.86 [DEBUG] computed 1 nodes in 0.024304 seconds. there are 12 total nodes.
# 2.14.0
The --no-pantsd --no-watch-filesystem
are prompted by https://www.pantsbuild.org/docs/prerequisites#macos.
Watching top (e.g. docker ps
to find the running container name, followed by docker exec -t ...name... top
) indicates that the memory usage of the pants python process is reasonable for a while, and then starts climbing to resident ~3.6G and virtual ~600G before succeeding. When running in a container with a lower memory limit (e.g. 3G), the server is killed instead (after the File handle limit is: 1048576
log line that's at 22:53:04.51
in the quote above).
Pants version
2.14.0
OS
macOS
Additional info
N/A
pantsbuild/pantsquaint-telephone-89068
11/23/2022, 3:46 PMA docker_image can depend on loose files belonging to file / files targets, and on artifacts packaged from a variety of targets, such as pex_binary , python_distribution, archive, or any other target that can be built via the package goal.This blog post has a good explanation of multistage builds - possibly this could be folded into the docs as an additional section. Additionally, details on supported inference for upstream docker images in the FROM instruction should be added. The multi-stage build support is an extremely useful feature in my view and it would be good to highlight it. pantsbuild/pants
quaint-telephone-89068
11/23/2022, 4:20 PM./pants
itself would run using 3.9 (while our "main" code continued to use 3.8). Afterwards, we started seeing ./pants package
fail with sha256 mismatch errors for one of our requirements:
There was 1 error downloading required artifacts:artifacts
1. clr 0.3.19 from git+<https://github.com/color/clr.git@a444a0612374a19f22e511b5e3514a60561e6160>
Expected sha256 hash of 88c4fc49003c1594d70aefe9cfbae3e60327a85e52e4608755f52cce2d438eb3 when downloading clr but hashed to 39cdfcc1e1980477476434e6d3d7777bc2bbecff7fcd903f36b4ddb1b17283a5.
@jsirois pointed out that the hash depended on the version of the interpreter building the sdist:
$ curl -sSL <https://github.com/pantsbuild/pex/releases/download/v2.1.114/pex> -O
$ PEX_SCRIPT=pex3 python3.7 pex lock create --style universal --target-system linux --target-system mac --resolver-version pip-2020-resolver "git+<https://githu/>
b.com/color/clr.git@a444a0612374a19f22e511b5e3514a60561e6160#egg=clr" --indent 2 -o lock.3.7.json
$ PEX_SCRIPT=pex3 python3.8 pex lock create --style universal --target-system linux --target-system mac --resolver-version pip-2020-resolver "git+<https://github.com/color/clr.git@a444a0612374a19f22e511b5e3514a60561e6160#egg=clr>" --indent 2 -o lock.3.8.json
$ PEX_SCRIPT=pex3 python3.9 pex lock create --style universal --target-system linux --target-system mac --resolver-version pip-2020-resolver "git+<https://github.com/color/clr.git@a444a0612374a19f22e511b5e3514a60561e6160#egg=clr>" --indent 2 -o lock.3.9.json
$ diff lock.3.7.json lock.3.8.json
52c52
< "hash": "39be551f54bc4c59210f08326bc649806d0ca18b8c008975424023cda2568782",
---
> "hash": "88c4fc49003c1594d70aefe9cfbae3e60327a85e52e4608755f52cce2d438eb3",
$ diff lock.3.7.json lock.3.9.json
52c52
< "hash": "39be551f54bc4c59210f08326bc649806d0ca18b8c008975424023cda2568782",
---
> "hash": "39cdfcc1e1980477476434e6d3d7777bc2bbecff7fcd903f36b4ddb1b17283a5",
Despite that, running ./pants generate-lockfiles
under Python 3.9 didn't change the expected hash in our lockfile.
Inspecting the package
and generate-lockfiles
processes, I found that:
1. package
was generating a process like $(which python) ./pex --lock <lockfile> <requirement>...
- in this case the Python 3.9 interpreter was selected, which was not compatible with the interpreter constraints in <lockfile>
2. generate-lockfiles
was generating a process that ran in a virtualenv - the virtualenv's interpreter was a symlink pointing at the system's Python 3.8 binary
As a user, now that I now the sha256 computation of sdists can depend on the interpreter version, I would expect ./pants package
to locate & use the same interpreter as generate-lockfiles
(or a "compatible" interpreter for some definition of compatible) to avoid this sort of mismatch.
Pants version
2.15.x
OS
Both
Additional info
At the pex level, the hash mismatch was caused by the use of setup-requires
in the requirement's setup.py
. It sounds like there isn't really a way around the problem within pex itself, so the idea here is to have Pants work around the issue automatically when possible.
pantsbuild/pantsuser
11/23/2022, 5:13 PMquaint-telephone-89068
11/23/2022, 8:39 PMquaint-telephone-89068
11/24/2022, 12:52 PMquaint-telephone-89068
11/24/2022, 12:59 PM.pants.bootstrap
shell script, it will be sourced before invoking your Pants command so any environment variables that needs to be set or other functionality you need to happen for each call to ./pants
may be placed into that file.
Example:
# .pants.bootstrap
# Ensure GIT_COMMIT is set
: ${GIT_COMMIT:=$(git rev-parse HEAD)}
# ...
Make sure you have these lines in your ./pants
script. If not you need to update your local ./pants
script first ;)
pantsbuild/pantsquaint-telephone-89068
11/24/2022, 1:11 PMvisibility
backend.
☐ #17632
☐ User feedback.
• #17660
• #17873
☐ Part of 2 stable releases.
☐ No outstanding issues affecting visibility rule semantics or APIs. (may not be marked as complete until all other tasks are marked complete)
pantsbuild/pantsquaint-telephone-89068
11/25/2022, 5:05 PM$ wget <https://github.com/pantsbuild/pex/releases/download/v2.1.108/pex>
$ PEX_PYTHON=/usr/bin/pypy3.8 /usr/bin/pypy3.8 ./pex -V
2.1.108
For 2.1.109 or newer:
$ wget <https://github.com/pantsbuild/pex/releases/download/v2.1.109/pex>
$ PEX_PYTHON=/usr/bin/pypy3.8 /usr/bin/pypy3.8 ./pex -V
Failed to find a compatible PEX_PYTHON=/usr/bin/pypy3.8.
Examined the following interpreters:
1.) /usr/bin/pypy3.8 PyPy==3.8.13
No interpreter compatible with the requested constraints was found:
Version matches CPython!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*,<3.12,>=2.7
Not a big deal because one can still create their own pex that doesn't have the interpreter constraint.
pantsbuild/pexquaint-telephone-89068
11/25/2022, 9:51 PM--resolve-local-platforms
option allows Pex to substitute a local interpreter for a --platform
whenever there is a local interpreter available that fits the abbreviated --platform
description. The option also applies to --complete-platform
and in either case the test of a match is here:
pex/pex/resolve/target_configuration.py
Lines 139 to 161 in </pantsbuild/pex/commit/b1343ffbc4ef58c456d072c4f700ad23f1f51743|b1343ff>
The test is that there is an intersection between the local interpreter's compatibility tags and those of the foreign platform. Intersection is problematic when the local interpreter supports newer ABIs than the foreign platform. In this case, the local interpreter is used as a substitute for the foreign platform which allows wheels with newer ABIs than the foreign platform can support to be resolved.
To correct this problem, a local interpreter should only be substituted for a foreign platform if its compatibility tags form a subset of the foreign platform tags. In the case of abbreviated --platform
there is not much that can be done differently than the current intersection test since the full accurate set of tags is unknown. For the --complete-platform
case, however, a subset relationship can be checked instead.
pantsbuild/pexquaint-telephone-89068
11/25/2022, 9:55 PMquaint-telephone-89068
11/26/2022, 12:20 AM23:45:02.29 [ERROR] Completed: Run Pytest - src/python/pants/core/goals/fix_test.py:tests - failed (exit code 1).
============================= test session starts ==============================
collecting ... collected 12 items
src/python/pants/core/goals/fix_test.py::test_summary PASSED [ 8%]
src/python/pants/core/goals/fix_test.py::test_skip_formatters PASSED [ 16%]
src/python/pants/core/goals/fix_test.py::test_fixers_first FAILED [ 25%]
src/python/pants/core/goals/fix_test.py::test_only PASSED [ 33%]
src/python/pants/core/goals/fix_test.py::test_no_targets PASSED [ 41%]
src/python/pants/core/goals/fix_test.py::test_message_lists_added_files PASSED [ 50%]
src/python/pants/core/goals/fix_test.py::test_message_lists_removed_files PASSED [ 58%]
src/python/pants/core/goals/fix_test.py::test_message_lists_files PASSED [ 66%]
src/python/pants/core/goals/fix_test.py::test_default_single_partition_partitioner[KitchenSingleUtensilFieldSet-field_sets0] PASSED [ 75%]
src/python/pants/core/goals/fix_test.py::test_default_single_partition_partitioner[KitchenMultipleUtensilsFieldSet-field_sets1] PASSED [ 83%]
src/python/pants/core/goals/fix_test.py::test_streaming_output_changed PASSED [ 91%]
src/python/pants/core/goals/fix_test.py::test_streaming_output_not_changed PASSED [100%]
=================================== FAILURES ===================================
______________________________ test_fixers_first _______________________________
def test_fixers_first() -> None:
rule_runner = fix_rule_runner(
target_types=[FortranTarget, SmalltalkTarget],
# NB: Order is important here
request_types=[FortranFmtRequest, FortranFixRequest],
)
write_files(rule_runner)
stderr = run_fix(rule_runner, target_specs=["::"])
# NB Since both rules have the same body, if the fixer runs first, it'll make changes. Then the
# formatter will have nothing to change.
> assert stderr == dedent(
"""\
+ FortranConditionallyDidChange made changes.
✓ FortranFormatter made no changes.
"""
)
E AssertionError: assert equals failed
E '\n+ FortranConditionallyDidCha '\n+ FortranConditionallyDidCha
E nge made changes.\n✓ FortranFor nge made changes.\n✓ FortranFor
E matter made no changes.\n\n✓ Fo matter made no changes.\n'
E rtranConditionallyDidChange mad
E e no changes.\n✓ FortranFormatt
E er made no changes.\n'
src/python/pants/core/goals/fix_test.py:342: AssertionError
- generated xml file: /tmp/pants-sandbox-oaXEIM/src.python.pants.core.goals.fix_test.py.tests.xml -
=========================== short test summary info ============================
FAILED src/python/pants/core/goals/fix_test.py::test_fixers_first - Assertion...
========================= 1 failed, 11 passed in 4.06s =========================
pantsbuild/pantsquaint-telephone-89068
11/26/2022, 11:53 AM.pants.d/pants.log
shows messages like
06:50:26.74 [INFO] notify invalidation: cleared 1 and dirtied 26 nodes for: {"", "ignored_dir"}
06:50:26.74 [INFO] notify invalidation: cleared 1 and dirtied 5192 nodes for: {"ignored_dir", ""}
I've created a fake PR #17641 to reproduce this exact issue
I'd argue that the pants_ignore
behavior seems to be correct. Even though "touch" actually changes the directory above, it's affecting a path we explicitly don't care about.
Pants version
Found on 2.13.0 but can repro on current main (ede74f2)
OS
Only tested on Linux
pantsbuild/pantsquaint-telephone-89068
11/27/2022, 2:38 AM-msan
option.
Note: The cgo support will also need to accommodate the memory sanitizer.
pantsbuild/pantsquaint-telephone-89068
11/27/2022, 2:01 PMCOPY --from=<BASEIMAGE> <FILES>
instructions. I am getting the following error: failed to compute cache key: <FILES>.
I also included the BASEIMAGE as a dependency but without effect.
Further information: https://docs.docker.com/develop/develop-images/multistage-build/#use-an-external-image-as-a-stage
Pants version
2.11.0
OS
WSL
pantsbuild/pantsquaint-telephone-89068
11/27/2022, 3:07 PM-asan
option.
Note: The cgo support will also n eed to accommodate the address sanitizer.
pantsbuild/pantsquaint-telephone-89068
11/28/2022, 12:40 AM./pants test ::
.
Have test file (Go) fail to compile.
My error [ERROR] Completed: Compile with Go - <redacted> failed (exit code 1).
Run echo $?
.
Expected:
A non-zero (failing) status code.
Observed:
A zero (successful) status code.
Pants version
2.14.0
OS
Only tested on Linux.
Additional info
Failing with a non-zero code is critical for correct use in CI. Basically every CI system will consider a command successful if the status code is 0. This breaks the ability to trust Pants output in CI.
pantsbuild/pantsquaint-telephone-89068
11/28/2022, 3:28 PMimport-linter
instead of the visibility backend 🤢
Additional context
AIUI, this would require changing the API of the dependency-rule system. Currently the core dependency resolution rule requests ValidatedDependencies
but throws away the result here:
pants/src/python/pants/engine/internals/graph.py
Lines 1304 to 1315 in </pantsbuild/pants/commit/a4054868c11690874005999cb80100e4da107538|a405486>
So implementations of ValidateDependenciesRequest
-> ValidatedDependencies
have no choice but to raise an exception on a dependency error, and the first error raised is the one that gets reported.
IMO a better API would always return a value - conceptually something like Rust's Result
, though I'm not sure how best to model that in Python. The core logic could then loop over all the results, log errors, and raise some error to bail out if needed.
pantsbuild/pantsquaint-telephone-89068
11/28/2022, 4:46 PMregex-lint
. Which doesn't technically belong in project_info
IMHO.
pantsbuild/pantsquaint-telephone-89068
11/28/2022, 6:04 PM$ curl -sSL <https://files.pythonhosted.org/packages/26/b4/356748c06781caabbc8f17d71b69a06a0efe14dd63dd199b9c29d1dbc85f/pantsbuild.pants-2.16.0.dev1-cp39-cp39-manylinux2014_x86_64.whl> -O
$ unzip -qc pantsbuild.pants-2.16.0.dev1-cp39-cp39-manylinux2014_x86_64.whl pantsbuild.pants-2.16.0.dev1.dist-info/METADATA | grep -E "^Version:"
Version: 2.16.0.dev1
$ unzip -qc pantsbuild.pants-2.16.0.dev1-cp39-cp39-manylinux2014_x86_64.whl pants/_version/VERSION
2.16.0.dev1+git57fecb6c
It appears this may be due to #17582 since there is no longer a `pants/VERSION`:
$ zipinfo pantsbuild.pants-2.16.0.dev1-cp39-cp39-manylinux2014_x86_64.whl | grep -E "pants/(_version|version)"
-rw-r--r-- 2.0 unx 1310 b- defN 22-Nov-27 18:01 pants/version.py
-rw-r--r-- 2.0 unx 23 b- defN 22-Nov-27 18:01 pants/_version/VERSION
-rw-r--r-- 2.0 unx 0 b- defN 22-Nov-27 18:01 pants/_version/__init__.py
And that is what we look for here:
pants/build-support/bin/_release_helper.py
Lines 984 to 990 in </pantsbuild/pants/commit/15750dbd534028ee17b16401eb49cd79d8495896|15750db>
The fix may be as simple as adjusting extra_globs
there.
pantsbuild/pantsuser
11/28/2022, 6:52 PMquaint-telephone-89068
11/28/2022, 7:46 PM./pants package ::
contain no source, and therefore do not work. The generated source tars are similarly barren. Pip, on the other hand, is able to create wheels just fine (after I remove the BUILD
file anyway since pip creates a directory called build
now).
The package in question uses pyproject.toml
. The BUILD file reads as follows:
resource(name="pyproject", source="pyproject.toml")
python_distribution(
name="dist",
dependencies=[
":pyproject"
],
provides=python_artifact(
name="example_package",
version="0.0.1",
),
generate_setup=False
)
BUILD files in the source directories just have python_sources()
.
pyproject.toml:
[build-system]
requires = ["setuptools", "setuptools-scm", "wheel"]
build-backend = "setuptools.build_meta"
[project]
name = "example_package"
version = "0.0.1"
description = "description"
authors = [{name = "example"}]
keywords = ["example"]
requires-python = ">=3.11"
license = {text = "Apache License 2.0"}
classifiers = [
"Development Status :: 2 - Pre-Alpha"
]
dependencies = [
"requests==2.28.1"
]
[tool.setuptools]
include-package-data = true
[tool.setuptools.packages.find]
exclude=["tests*"]
The source directory structure looks something like:
.
├── BUILD
├── <http://MANIFEST.in|MANIFEST.in>
├── NOTICE
├── README.md
├── pyproject.toml
├── example_package
│ ├── BUILD
│ ├── __init__.py
│ ├── py.typed
│ └── example.py
└── tests
├── __init__.py
└── unit
├── BUILD
├── __init__.py
└── test_example.py
The generated tar contains the following:
example_package-0.0.1
├── PKG-INFO
├── backend_shim.py
├── pyproject.toml
├── setup.cfg
└── example_package.egg-info
├── PKG-INFO
├── SOURCES.txt
├── dependency_links.txt
├── requires.txt
└── top_level.txt
Note also backend_shim.py
- why is that there?
The generated wheel only contains the dist-info directory, no source at all.
Pants version
Which version of Pants are you using?
2.14.0
OS
Are you encountering the bug on MacOS, Linux, or both?
macOS, I haven't tested on Linux
Additional info
Add any other information about the problem here, such as attachments or links to gists, if relevant.
pantsbuild/pants