Sorry for delay in reply; I'm out of town, will look at it when I get back tomorrow..

I did mean

:server

since the pex is what the docker image consumes. And the

server

target should have a dep on

:bar

, since that is what it consumes in turn.

And I think you need to be on 2.8.0rc0 ?

Which Pants version are you on?

So I have some (non-python) files in my monorepo that are generated from other files. An easy example is we generate GitHub's CODEOWNERS from a yml file (for ease). Ideally, this functionality would sit in my build tool (E.g. it knows that script X generates CODEOWNERS from CODEOWNERS.yml). That way: • If CODEOWNERS.yml gets touched it could re-generate (given the right command, like

fmt

) • If CODEOWNERS isn't what we expect due to changes in CODEOWNERS.yml, we error on the right command (like

lint

?) • If someone touches CODEOWNERS but not the yml, also error in a command (like

lint

) Any thoughts on this inside of Pants (I presume as a plugin)

Haven’t worked in our python/pants repo in a while and (probably after upgrading to BigSur), I get this system popup every time I run pants. I tried reinstalling the python version pants is using (with pyenv), but that did not help. We’re on the latest stable pants version.

Does

pants

have a

clean

equivalent? Specifically looking to clean: • The cache • Previously leaked tempdirs used for debugging

hey team. When having a constraints file (generated from the

requirements.txt

file), I configure

pants.toml

to be:

[python-setup]
...
requirement_constraints = "constraints.txt"
resolve_all_constraints = false

When running the tests, I can see this being printed:

Starting: Building requirements.pex with 4 requirements: PyYAML, dataclasses==0.6, marshmallow>=3.5, requests>=2.22

Does it mean that Pants ignores the

constraints.txt

file? I’ve left a dependency out of the

constraints.txt

on purpose and got this message, so Pants must be able to find it

The constraints file constraints.txt does not contain entries for the following requirements: elasticsearch

https://twitter.com/sluongng/status/1453440610854133761 Pants Build retweeted: Wild/chaotic episode but very insightful on how you can build custom tooling based on git-worktree and get amazing… https://twitter.com/i/web/status/1453440610854133761 Twitter Excited for @VimconfLive 2021? Join us tomorrow for Dev Tool Time, where @ThePrimeagen will join @TeejDeVries and… https://twitter.com/i/web/status/1453162783147708417 Twitter

https://twitter.com/pantsbuild/status/1453514032963588101 Pants 2.7.1, the second stable release in the 2.7 series, is out. Thanks to all the contributors! https://pypi.org/project/pantsbuild.pants/2.7.1/ Twitter

so, my

./pants --changed-since=origin/master list

no longer works... on CI. locally works fine:

╰─➤  git --version
git version 2.30.2

╰─➤  ./pants --changed-since=origin/master list      
14:33:17.78 [INFO] Initializing scheduler...

but on ci... fails:

$ git --version
git version 2.20.1

$ ./pants -ldebug --changed-since=$CHANGED_SINCE list
01:32:16.80 [DEBUG] Detected git repository at /builds/infloai/repo on branch None
01:32:16.80 [DEBUG] Executing: git --git-dir=/builds/infloai/repo/.git --work-tree=/builds/infloai/repo diff --name-only HEAD -- /builds/infloai/repo
01:32:16.83 [DEBUG] Executing: git --git-dir=/builds/infloai/repo/.git --work-tree=/builds/infloai/repo diff --name-only origin/master...HEAD -- /builds/infloai/repo
01:32:16.84 [ERROR] git --git-dir=/builds/infloai/repo/.git --work-tree=/builds/infloai/repo diff --name-only origin/master...HEAD -- /builds/infloai/repo failed with exit code 128
(Use --print-stacktrace for more error details and/or --no-process-execution-local-cleanup to inspect chroots. See <https://www.pantsbuild.org/v2.7/docs/troubleshooting> for common issues. Consider reaching out for help: <https://www.pantsbuild.org/v2.7/docs/getting-help.>)

hey team. Is there a prettier way to package all

pex_binary

targets in a particular project within a Pants monorepo than doing:

./pants filter --target-type=pex_binary --filter-address-regex="myproject" :: | xargs ./pants package

?

@stale-nightfall-29801 I’m finally back at the “office”. If you add a dependency from your

docker_image

to the pex binary

:server

as Benjy suggested, then run

./pants -ldebug package bar:docker

and check for the log that reads

"Packages for Docker image: …"

should tell you what the pex binary name is that you can use.

logs.txt

I can't seem to see the

pex

binary in this:

relevant section of BUILD:

docker_image(
    name='docker_server',
    dependencies=[":bar"],
    sources=["Dockerfile"]
)

Sorry forgot to @curved-television-6568 ☝️, thanks again for all the help

Hi, change

dependencies=[":bar"],

to

dependencies=[":server"]

which is the name of your pex binary target.

Thank you for your patience troubleshooting this experimental feature! 🙂

Lessons learned here will help us improve the experience going forward..

Is there a way to know which version of Python

pants

is running & using for it's internal rules? I just noticed if I run

pants

from within/without some virtual env I have, it'll toggle between 2.7 (system-default) or 3.8 (virtual environment version)

Is there any way to get more detailed git errors? I am trying to use

--changed-since

in our CI system and and get this error

Error: 6.70 [ERROR] git --git-dir=/home/runner/work/color/color/.git --work-tree=/home/runner/work/color/color diff --name-only master...HEAD -- /home/runner/work/color/color failed with exit code 128

. Not sure how to debug this further without a more detailed error message?

I'm updating to version 2.8.0rc0 and running into this error:

Traceback (most recent call last):
  File "/home/maier/.cache/pants/setup/bootstrap-Linux-x86_64/2.8.0rc0_py37/lib/python3.7/site-packages/pants/engine/internals/selectors.py", line 711, in native_engine_generator_send
    res = func.send(arg)
  File "/home/maier/.cache/pants/setup/bootstrap-Linux-x86_64/2.8.0rc0_py37/lib/python3.7/site-packages/pants/backend/python/util_rules/pex.py", line 441, in build_pex
    resolve_name,
  File "/home/maier/.cache/pants/setup/bootstrap-Linux-x86_64/2.8.0rc0_py37/lib/python3.7/site-packages/pants/backend/python/util_rules/lockfile_metadata.py", line 126, in from_lockfile
    concrete_class = _concrete_metadata_classes[metadata["version"]]
KeyError: 'version'

This is when I'm trying to run

./pants update-build-files

to update things. Has anyone run into this before?

It also appears to happen when I run any pants command, really

I updated another repository to Pants 2.7.1 (I like to keep one of our repos on the bleeding edge, and the others on stable) and found that a few pex packages we generate were broken; they both complained that one of our modules wasn't present, when it was definitely in the pex. I narrowed the issue down to the 2.7.1rc0 release with all the pex-related updates. Apparently, our pexes were being run with `execution_mode="venv"`; switching them over to

execution_mode="zipapp"

with 2.7.1rc0 seems to fix the issue. I'm not a Python packaging expert by a long shot, so I'm not entirely sure how this distinction would have such a big effect. Has anybody else seen this? Is there additional information I could provide that might be useful here? Thanks in advance 🙇

Is there anyone on the Slack who speaks Persian? I'm hoping there's a user or two who can share their personal thoughts with this user. Thanks! https://twitter.com/muhammadddev/status/1453776516018581508

hey team. I am migrating a legacy project that relied on using

pkg_resources

to get the version of the package at the runtime (to be put into some logs/reports — to tell what version was used for producing the outputs).

from pkg_resources import get_distribution
get_distribution("my_project").version

Now, the package is not installed any longer as a wheel and instead is run as a PEX file (and of course it doesn’t have a “version” any longer). What approach do people take when they need to access the version dynamically when running the code? I see https://github.com/pantsbuild/pants/blob/main/src/python/pants/version.py#L13-L18 but curious what other clever tricks others have came up with 🙂

would be amazing if

--pytest-args="--pdb"

automatically gave pants the right set of flags to work

Overall I love that BUILD files are now linted with Black but I do kind of wish that it somehow favoured newlines more than it does.

pex_binary(name="manage", entry_point="manage.py", dependencies=["src/mysite:mysite", "src/polls:polls"], restartable=True)

VS

pex_binary(
    name="manage", 
    entry_point="manage.py",
    dependencies=[
        "src/mysite:mysite", 
        "src/polls:polls"
    ],
    restartable=True
)

I much prefer the second one - it makes diffs so much more readable. Guessing this is configurable if I look for the option but maybe we want to override the defaults on Black for this use case out of the box?