thanks to @witty-crayon-22786 for help on the performance investigation here and for suggesting criterion

created a draft pantsbuild/binaries PR for downloading the rust toolchain: https://github.com/pantsbuild/binaries/pull/97

first draft of a rust backend!!! https://github.com/pantsbuild/pants/pull/9781. it seems to work and is pretty fast with the SnapshotSubset() optimization

sketch of a design for “mutable” (somewhat) process caches: https://docs.google.com/document/d/1n_MVVGjrkTKTPKHqRPlyfFzQyx2QioclMG_Q3DMUgYk/edit?usp=sharing (accessible to pants-devel@) … feedback welcome!

Interesting proposal from 2016: move all Pants folders into a

.pants

folder. Possibly, keep

dist/

. We rejected it then because of the

clean-all

goal’s behavior, but we could change how that goal behaves. https://github.com/pantsbuild/pants/issues/3511

clean-all

doesn’t affect v2 at all =x … some semantics to figure out there.

@happy-kitchen-89482: https://github.com/pantsbuild/pants/pull/9799 is a pretty substantial change in behavior, haven’t reviewed yet, but it might be worth gathering wider feedback on

@hundreds-father-404, @hundreds-breakfast-49010: https://github.com/pantsbuild/pants/pull/9797 might look hairy, but the key thing is just that errors with traces get much more compact, and render only the Nodes with `user_facing_name`s: would appreciate a look today when you get a chance

Hello. I’m trying to refactor

BuildFileAddress

, such as getting it to no longer subclass

Address

but instead compose it with a dataclass (long standing TODO). I think it’s too entrenched to get right, though. It’d be easiest to start from scratch. The only issue is the name. I like

BuildFileAddress

, but it’s claimed. Thoughts on

BuildAddress

? Any suggestions on other names?

AddressWithBuild

?

AddressWithBuildPath

? The TODO from Benjy suggests ~ this design, which I think makes sense:

@dataclass(frozen=True)
class AddressWithBuild
  address: Address
  build_path: str

now that the fix for the console UI bugs is in, is there anything blocking https://github.com/pantsbuild/pants/pull/9775 ? @witty-crayon-22786 @hundreds-father-404

oo. maybe not…?

I don’t think so!!

cool, I'll merge when CI passes then

… 1.29.x might be huge (in a good way!)

i wouldn’t be opposed to cherry-picking that to 1.28.x though… i should have thought about it before pushing on rc2.

That goes against our release strategy imo. I would leave the UI for 1.29. We aren’t supposed to do new features in RCs

And we might want to make 1.29 be only 2-3 dev releases, given the user feedback that releases have been too big recently

@hundreds-father-404: hm, we might want to tweak that then. rcs before a stable release aren’t supposed to themselves be considered stable

*release strategy, not deprecation policy

They’re “more stable than a dev release, but not as stable as a stable release” imo

I think that’s important to convincing orgs to try out RCs. They won’t tolerate too much instability

we cherry picked other deprecations there … this is similar i think.

fine with letting it go and just focusing on moving forward on a good cycle.

I’m starting to look at adding support for a) codegen to synthetically inject runtime dependencies, and b) “dependency inference” (meaning you can leave off

dependencies

in your BUILD file and Pants will do the right thing based on import statements) -- We need to convert

Dependencies

from a

PrimitiveField

to

AsyncField

so that the engine can do its magic. Call sites would look like:

await Get[Addresses](DependenciesRequest(tgt.get(Dependencies))

This means we have one rule to go from

DependenciesRequest -> Addresses

, just like we have one rule to go from

HydrateSourcesRequest -> HydratedSources

. Fine and good. -- The challenge is with codegen dependency injection. Specifically, that that injection will need to access subsystem options, e.g.

--protoc-runtime-targets

. It will need a

SubsystemRule

. But, we can’t have our generic

DependenciesRequest -> Addresses

rule request that subsystem because it has no idea it’s needed. Instead, in the rule, we need a way to say something like “If there are any injected dependencies for this

Dependencies

field, run the rule to inject those.” This is unions, right? Something like:

injected_deps = await Get[InjectedDependencies](InjectDependenciesRequest, dependencies_field)

And then the Protoc backend would define a rule that goes from

(ProtocDependencies, Protoc) -> InjectedDependencies

, where

ProtocDependencies

belongs to the union?

the requested sources type needs to come into play there somewhere…

…oh. i see what you’re getting at. that the Dependencies field would be subclassed. hm, yea

something about that feels strange, because for sources, the conversion is

ProtocSources

->

PythonSources

… the analogue here would be to use typed dependencies in all cases too?

PythonDependencies

…?

the

DependenciesRequest

would need output type information, basically.

something about that feels strange, because for sources, the conversion is ProtocSources  -> PythonSources

This is not true. The conversion is

HydrateSourcesRequest(ProtobufSources) -> HydratedSources

. We only use

PythonSources

as a way to express intent that “I want this to be something like PythonSources”. I don’t think we need that notion here. You will always get all dependencies - the call site can filter out irrelevant ones, like how we do currently in

importable_python_sources.py

. Part of the reason we do not need to specify the “output type” is that there’s no ambiguity problem, here. With codegen of sources, you can go from ProtobufSources to multiple different languages, but you only want one distinct language. With dependencies, it’s fine for us to add all the runtime dependencies; it’s acceptable afaict if we always injected a

JarLibrary

,

PythonRequirementLibrary

, etc, when calling

await Get[Addresses](DependenciesRequest(protobuf_library[Dependencies])

. The call site can ignore the

JarLibrary

if it wants to