FYI docs updated for Python codegen with the improvements made this week. Quick review would be helpful when folks get a chance 🙂

I’m seeing

DependenciesRequest

return a

java_source

target as its own dependency, but I don’t see that behavior for a

scala_source

target.

FYI 2.10 release blog. Comments are welcomed https://docs.google.com/document/d/1rNkK8ToLMvTv4rXq_qUwvkXOcPxVYTZigaUnUhOsFNg/edit?usp=sharing

@bitter-ability-32190 congrats on replacing all of Pants to use the new Options API! So much better. Great work 🎉 The only thing that gives me pause before we deprecate the old API in favor of this new one is https://github.com/pantsbuild/pants/issues/10360. We don't need to implement it, but should confirm we can fix using the new API

Re 2.11 release timeline x Pex lockfiles:

@hundreds-father-404: oh! … i understand now what you mean by a module mapping for codegen targets. that’s basically akin to treating them as thirdparty

I fleshed out the section on

py-spy

in the docs: https://www.pantsbuild.org/v2.10/docs/contributions-debugging If folks think it's good I'll copy to the other pages.

🎣 for feedback on my `fmt`+`lint` use the same process proposal: https://docs.google.com/document/d/1KqrPP6VVi-Kq8EUqfo2IFffaHxdysCMPwrInoewM-LM/edit?usp=sharing

It's surprisingly little code for us to support pex.py installing a lockfile from either Pex's JSON format vs. normal requirements.txt-style. We do still want to change Pants's

generate-lockfiles

to always generate using Pex JSON. But do we think it's valuable to indefinitely let users keep manually generating their requirements.txt style lockfiles, e.g. via pip-compile or poetry export?

JVM codegen thread

@witty-crayon-22786 (and cc @enough-analyst-54434), curious your thoughts on

available_concurrency

for building a PEX x lockfiles:

is there any way to filter a list of

ClasspathEntry

down to just those generated from a

jvm_artifact

?

Hello! Just an FYI: as requested by @happy-kitchen-89482, I opened an issue for Cython Support (https://github.com/pantsbuild/pants/issues/14752), I also created a repo for showcasing what I've done so far (https://github.com/houtenjack/pants-cython-minimal-example). Feel free to fork it if you are interested or have some inputs!

Huh @enough-analyst-54434 Pex CI failed for only one job and GitHub says "This Check Failed" with no output: https://github.com/pantsbuild/pex/runs/5500096932?check_suite_focus=true. I can't find any logs elsewhere. Probably a GitHub flake? Fine for me to restart?

In a

BuiltinGoal

, how do I access the environment?

os.environ

is empty except for

PANTS_BIN_NAME

. Do I need to make an

EnvironmentRequest

to the engine?

Hey alternative angle for Pants 2.10 third-party dependency management...

Q: Why is having no constraints/lockfile of any kind even supported? Seems so goofy to me

I've been meaning to post this one for a while. I want a decent # of approvers to show consensus. PR to change the Unicode character for the "failed" sigil: https://github.com/pantsbuild/pants/pull/14764

2.11 release timeline: we've already done

dev3

, which means we're supposed to start

rc0

today/this weekend per our release strategy. We reflected in Pants 2.8 it was bad we violated this. Anyone trying to get things into 2.11 still?

FYI the pinned Toolchain plugin doesn't use the new options types. I noticed when I started working on a PR to deprecate the old way 😉

🎣4️⃣👨‍🍼🔙 on some PRs Python asset inference: https://github.com/pantsbuild/pants/pull/14049 Deprecating

register_options

https://github.com/pantsbuild/pants/pull/14772

Made some progress today on building images for arm64 builders, but hit a bit of a snag with the Packer recipes i've found that try to fully replicate a GHA runner with all of Actions' Virtual Environments installed. (For example, this wants to install Homebrew, which doesn't seem to work out of the box on Linux on ARM). But I don't think we need that? I'm guessing it might be best to go for a simpler approach that just installs docker and then we can build a docker image off

<http://quay.io/pypa/manylinux_2_24_aarch64|quay.io/pypa/manylinux_2_24_aarch64>

with a rust toolchain installed in it? I'm not sure what all is needed to build pants or run GHA, but doing something targeted has got to be easier than a kitchen sink approach, right?

I thought homebrew was a MacOS thing

The x86_64 Linux image we use for CI seems like a good basis to crib off?

Not in front of my laptop but you should be able to find references to it in the repo

Brew on linux unfortunately become a thing at some point, I think because people who were used to it didn't want to learn rpm/deb to distribute (don't really blame them, but adding another packaging format and distribution channel doesn't solve that problem 🙃) and also many linux streams are really behind

Hi all! I've been looking into improving the newly added protobuf linting by also adding support for

buf breaking

. I have a few questions though since (to me) adding and using it is not as straight forward as a normal linter is. See thread!

buf breaking

needs a previous state to compare against in order to detect breaking changes. My naive approach is to simply piggyback on Pants'

pants.base.build_environment.get_git

and

pants.vcs.changed.ChangedOptions

functionality.

get_git

to get the git workdir (from the currently protected

_gitdir

attribute) and `ChangedOptions.diffspec`/`ChangedOptions.since` to get the rev to compare the local tree against. If `ChangedOptions.diffspec`/`ChangedOptions.since` it can fall back on

HEAD

, and if

get_git

returns

None

then the linter will be skipped I guess? I'm not entirely sure how to put it all together.

get_git

seems to be callable from anywhere, so that should be simple enough, but

ChangedOptions

I'm struggling to get into my linter rule, probably because it's not intended to be used directly by rules but rather to determine which sources to provide the rules with. I'm also pondering about on how to structure the code and its options. The current linter is located in

pants/backend/codegen/protobuf/lint/buf

. Is this even a linter, or is a test or a check? Right now I've renamed the current

rules.py

to

lint_rules.py

and have introduce

breaking_rules.py

. I imagine people will want the option to only enable/disable one of them, so bundling them in the same backend might not be the best approach. Then there's also the subsystem which I, of course, want to reuse for both, but should it be extended so

lint

and

breaking

have different

options_scope

perhaps? I appreciate any and all feedback 🖖

(Just replying to your middle paragraph, I have no idea about the rest) You can request any subsystem from any rule, so to access

ChangedOptions

just have your rule take in

Changed

as a parameter. Then use

changed.<attr>

Hey @narrow-vegetable-37489! Git is not really safe to use right now with the Rules API, we break the engine's sandbox when using it. The only place we use it is before the normal rules have fully kicked in,

specs_calculator.py

. https://github.com/pantsbuild/pants/issues/13724 tracks this - if you're interested, we'd be happy to write instructions Re different backends, it sounds like

breaking

might align with our notion of

check

than

lint

-

check

is intended for heavier weight-things like typechecking and compilation