Any conceptual opposition to renaming

optionable_rule

to

subsystem_rule

? The only time we use it is when registering a Subsystem with the engine — I don’t think we need the flexibility that comes with

Optionable

The first time I read

optionable_rule

, I mistook it for

optional_rule

, which confused me. Likewise,

Subsystem

is a more concrete concept than

Optionable

hm, I'm still playing around with this, but it seems like if we just run

strip

on the

libengine_cffi.so

binary that cargo outputs, we can reduce the size from ~160 MB to 12 MB

which I think the bootstrapping shell script could do fairly easily. and this would go a long way towards de-facto solving the problem of the engine .so getting materialized a bunch of places

are there any use cases where people are going to miss having debug symbols in the .so?

I haven't personally ever used gdb or similar when trying to debug pants

hm, I see that we apparently explicitly turn on debug symbols in release in Cargo.toml, which implies this is a deliberate decision

cf. the discussion on my HTTP intrinsic draft PR (https://github.com/pantsbuild/pants/pull/8834)

I wrote up a design doc: https://docs.google.com/document/d/1CdlGMXWxdwpGqet7-k6DFIbg90IqR75cFg8SkRu06H8/edit# @happy-kitchen-89482 @witty-crayon-22786

@average-vr-56795 @fancy-motherboard-24956 @red-balloon-89377 @early-needle-54791 (who else should be credited?) writing tests for this new feature i'm thinking of adding to

store::local::Store

is super nice!!! thank you for turning the v2 CAS fs api into such a joy!

https://github.com/pantsbuild/pants/pull/8892 is a mitigation for the running out of disk space issue

https://github.com/pantsbuild/pants/pull/8905 may also be a mitigation for the running out of disk space issue (avoid copying files to a hermetic sandbox and instead using symlinks if they're materialized commonly enough)

Hey @hundreds-father-404! Funny story! Internally at Twitter we have a goal called

scalafix

which does the equivalent to your

--fmt --fmt-only=scalafix

proposed flag! I know this because when you added the

Scalafix

subsystem, and took the option scope, we started getting errors 😄 How sad would you be if I added a v1

--fmt-only

flag which only accepts not being set, or accepts exactly

scalafix

(i.e. not do the fully general solution) to help us with migration?

sidenote: i'm going to do some review, but please hold off on landing things until the release goes in

sorry bout that

First proposed change to prepare for `non-target specs`: rename

Spec

to

AddressSpec

. Why? We don’t want to expand the current definition of

Spec

to include files - it’s a very useful abstraction as is, e.g. that we have logic for

SingleAddress

. At the same time, “specs” is a very useful namespace to describe your specifications for what you want to run against. We would have

AddressSpec

, and

FileSpec

(maybe

DirectorySpec

?). All of these things are `Spec`s. This is a more sound model than something like

Spec

,

File

, and

Directory

, which are all

PositionalArg

.

PositionalArg

is an implementation detail - the real core idea is that this is a specification for something to run against. -- Thoughts and/or opposition?

Do we actually still need the

@rule

decorator?

Followup to

AddressSpec

discussion. I think the other type of top-level

Spec

should be a

FilesystemSpec

, which may either be a

FileSpec

,

DirectorySpec

, and some still-unknown type for globs. Rules would then request

AddressSpec

or

FilesystemSpec

It wasn’t clear to me until recently that

FileSpec

and

DirectorySpec

need to have the same superclass so that rules can request

FilesystemSpecs

without caring whether users specifying them as files or directories, just as they don’t care how

AddressSpecs

were specified on the command line. Sound good?

Interesting… v2 goal options don’t get the same implicit scope-shortening as v1 goal options do… I kind of like that, but is it intentional?

what do you mean?

I tried out https://github.com/pantsbuild/pants/pull/8827 and

./pants test --debug

didn’t work but

./pants test --test-debug

did

hm. that's not expected. probably a function of them having a legacy of being subsystems as an implementation detail

Didn't we plan to get rid of that though, in v2, as being unnecessarily complicated?

Is

TransitiveHydratedTargets.closure

in topological order? What is the canonical way to get the dep closure of some targets in t-order?

I’d love to get rid of the feature in V2. It was the source of so much confusion for me and the other interns at Foursquare.

it could make options parsing a lot nicer to not have to know all the subsystem and task scopes beforehand

hm. people would really rather

./pants test --test-debug

...?

that doesn’t seem to make sense to me, i was just referring to the

goal.task

syntax which i was under the impression was the confusion everyone is speaking of

i was just referring to the goal.task syntax

Ah, that’s going away no matter what because there won’t be any more tasks

correct.

there won’t be any more v1 tasks, but not sure that means we would necessarily want to disallow the syntax for v2 purposes