my team has a split between macos and linux for local dev boxes. we’re also using the pex-based lockfiles from 2.11. we’ve noticed recently that PRs which modify the locks will update the value of

platform_tag

in each lockfile from:

"platform_tag": [
  "cp38",
  "cp38",
  "macosx_12_0_x86_64"
]

to:

"platform_tag": [
  "cp38",
  "cp38",
  "manylinux_2_31_x86_64"
]

and vice-versa, depending on the OS of the developer making the change we haven’t noticed any negative results from this other than confusion during code review, and I see artifacts for all platforms listed in the lockfile regardless. what’s the purpose of

platform_tag

? do we need to worry about it flapping back and forth between values?

Is there a best practice of how to set up a monorepo while planning to contribute to pants/running trunk?

i would prefer not having to keep all the CI/organizational stuff at the base of my personal monorepo 😅 edit: nevermind, I am blind. https://www.pantsbuild.org/docs/running-pants-from-sources

Q. When applying caching to Pants with GitHub Actions, is it enough to set the cache key as

${{ runner.os }}-

only as the doc/example suggests? The workflow log always says that "it is not saving the cache because the cache is hit", meaning that any newly updated contents would not reside inside the cache.

Ideally, we should use

hashFiles()

or some other mechanism that lets

actions/cache

know if the cache requires update.

Would it be the right place to use

hashFiles()

against the lock files and

pants.toml

, for instance?

“.. he'll grab one while the other slips away.” ? Maybe 😆

Haven't tried, but will report back when I can get the dev with a pycharm license to test it

Hi, is it possible to use

pants

with aws codeartifact? I see internally we are using it with npm packages. Codeartifact does support pip. Not sure how would I integrate it with pants though?

yes. we use this. you can see it here: https://github.com/toolchainlabs/remote-api-tools/blob/main/.github/workflows/build.yaml#L26

Is there an alternative to pystache or MustacheRenderer in pants 2.11? I've got two plugins that used pystache for templating and creating files based off targets passed in.

Is it possible to run multiple python versions of pants targets at a time? I'd like to simulate (or even just directly use) tox and run pytest in multiple versions of python to ensure compatibility. Maybe other targets as it makes sense.

Sometimes I think our subsystem schema is a bit haphazard 😕

After seeing the amount of careful thought you put in your last design doc, I look forward to reading a treatise eventually on rethinking the subsystem schema.

I still owe the shared folder a new one for

./pants run

. Having so many ideas is hard work 😅

I suspect that telling you to have fewer ideas would be fruitless...

Well with a tool as flexible and adaptable, and a community as welcome it's hard not to feel inspired

Awww 💕

Hey, we are trying to add

firebase-admin==5.2.0

as a python dependency to our project, but when I run

./pants generate-lockfiles --resolve=python-default

it seems to hang on "Generate lockfile for python-default" (now for 1 hour), is there any way to debug this?

Thinking cap time... 🧠 🎩 We have a lot of scripts in our repo, and to mitigate the need for mapping where the live we have a dir tree in our repo which houses "commands" where the dirnames become (sub)commands. Each script is a just a thin shell wrapper shelling out to the real Python script. E.g.

./script-runner devops docs generate

would invoke a shell script at

/scripts/devops/docs/generate.sh

, in turn that script run

./pants run path/to/the/script.py

. Now we can rename or move or change implementations without rewiring brains or other scripts. I want to "bring this into Pants" a bit more, if nothing more than to ensure the Pants spec in the shell script is valid. My thoughts are: • Try and implement a linter for these scripts. Match probable pants commands and specs and then error if the spec isn't valid • Bring the whole system into pants. Then the world is my oyster with a new goal, could be a single TOML file or spread or whatever. Lots more thought and plumbing though Anyone else do something similar? Have ideas?

Hey folks, just started looking into Pants as a replacement for Bazel for our python monorepo. It's been great to work with so far/wiring up our basic python sources & unit tests was fairly straightforward. The next step is to start migrating individual modules that explicitly depend on the structure of the bazel runfiles tree etc to weaken some assumptions that are made. Does anyone else here have experience migrating from Bazel to Pants that'd be game to chat/answer some other questions?

Hey everyone, I’m debugging a strange issue with running a service built with

python_awslambda

, with this resolver error being raised when the function is invoked:

[ERROR] ResolveError: A distribution for orjson could not be resolved in this environment.Found 1 distribution for orjson that do not apply:
1.) The wheel tags for orjson 3.7.1 are cp38-cp38-manylinux_2_28_x86_64 which do not match the supported tags of DistributionTarget(interpreter=PythonInterpreter('/var/lang/bin/python3.8', PythonIdentity('/var/lang/bin/python3.8', 'cp38', 'cp38', 'manylinux_2_26_x86_64', (3, 8, 13)))):
cp38-cp38-manylinux_2_26_x86_64
cp38-cp38-manylinux_2_25_x86_64
cp38-cp38-manylinux_2_24_x86_64
cp38-cp38-manylinux_2_23_x86_64
cp38-cp38-manylinux_2_22_x86_64
cp38-cp38-manylinux_2_21_x86_64
...

Does anyone happen to know what can be done here? Am I to believe that the

cp38-cp38-manylinux_2_28_x86_64

platform is not compatible with that of the lambda runtime?

👋 Hi everyone!

Getting this error :

pex.pex_builder.InvalidExecutableSpecification: Could not find script 'dagster api grpc --use-python-environment-entry-point -h 0.0.0.0 -p 4321 -f ./jobs/repository.py' in any distribution within PEX!

random question i was asked today (I searched and couldn’t find anything on the about page or anything else.) : why is the build tool called “pants”?

Are there any tricks for getting VSCode to see generated Python code in

dist/codegen

? E.g.,

_pb2.py

from

protobuf_sources

. Pointing VSCode at the virtualenv created by

pants export

gives me a mostly usable VSCode experience, but I still get mypy errors inside VSCode about missing

_pb2

modules. I found that I can add symlinks in the same directories as my

.proto

files that point to the generated files in

dist/codegen

. And add

*_pb2.py

and

*_pb2.pyi

to

.gitignore

. But this feels, uh, pretty kludgy.

Has anyone else had issues with

./pants publish

being rather flaky when building docker images? --> 🧵

I want to parametrize

resolve

for all

python_sources

targets. Is it possible to configure

./pants tailor

to do that when adding more targets? I tried to make a macro, for use with https://www.pantsbuild.org/docs/reference-tailor#section-alias-mapping, but I got an error:

Exception: Error parsing prelude file pants-plugins/macros.py: name 'parametrize' is not defined

My underlying motivation is very similar to https://pantsbuild.slack.com/archives/C046T6T9U/p1651762568623679?thread_ts=1651755337.307249&cid=C046T6T9U but for torch instead of jax.

I would like to generate Python codes for protocol buffer in version 3 with optional fields like following. Protobuf >= 3.15 supports

optional

keyword, so it should be compiled successfully (I already tried on protoc >= 3.15 and checked that it was compiled without errors)

syntax = "proto3";

package testing;

message SomeRequest {
  string required_field = 1;
  optional int32 optional_field;
}

However, when I execute

./pantsexport-codegen ::

, it said

Explicit 'optional' labels are disallowed in the Proto3 syntax. To define 'optional' fields in Proto3, simply remove the 'optional' label, as fields are 'optional' by default.

. How to resolve it ?