Also, is building via

./pants list 3rdparty::

sufficient for manual testing. As in, if I make changes and rebuilt the rust engine, does running

./pants

(killing/restarting daemon as appropriate) automatically use the new code, or is there some deploy or flags that have to be used in order for that to happen?

that should be fine, yea. and also, yes: the daemon watches a bunch of file paths, but it does not watch enough stuff to automatically restart it when developing the rust code, unfortunately. that could probably be tweaked, since we support adding additional manual paths? but for now, manually restarting the daemon

i usually have the daemon turned off when developing against the pants repo since it would need to be restarted almost every pants invocation anyway. it would also be neat to restart the daemon immediately whenever code is changed (not just the first time pants is run after code is changed)

he needs it in this case, since he's working on https://github.com/pantsbuild/pants/issues/4999

HYPE

ok, great thanks. Totally fine that it doesn’t auto-restart when it sees engine code changes. That would be fancy! If I want to try this out on a different repo for benchmarking, I assume I do something like

./pants bundle

and then untar the bundle (or whatever) in the other repo?

To try things out in abother repository, you'd want to refer to repo-specific instructions. If you're talking about the repo I think you're talking about, I can send you a link offline.

has anyone figured out a fix for this issue beside restarting your machine? I’ve run into it a few times in the last two days:

Exception: Could not initialize store for process cache: "Error making env for store at \"/private/var/folders/cf/z3ktw6dn467gvm24fgx8ft6c0000gp/T/tmpk1bj57ql/processes/7\": No space left on device"

@average-vr-56795 fyi

./pants --no-v1 --v2 test --debug src/python/pants/rules/core:tests

works for me on master branch.

@hundreds-breakfast-49010: it's probably time to turn

--v2-ui

on by default... thoughts?

totally unrelated, but: it looks like

src/python/pants/backend/python/rules/inject_init.py

is not using

InputFilesContent

it's been super super easy for me to use the black formatter with 2 spaces by just checking a wheel into this external repo using pants that i'm doing other stuff in and adding it to the pythonpath in pants.ini, so not clear whether specific support for 2-space indent is necessary in pants itself

I think there's some confusion among different pants developers over how we ultimately want rule cacheability to work, that's manifested as different people submitting PRs that make incompatible assumptions about what we should be building towards

the slack wysiwyg editor makes my heart hurt

One pager for file system specs, particularly how rules will consume this. I bolded the two key arguments I’m making. Thoughts appreciated! https://docs.google.com/document/d/15xphZcFnowytF0Qu2sO1PG7wHAWoyLof7hK0jVa5T8E/edit#

@hundreds-father-404 I updated https://github.com/pantsbuild/pants/pull/8922 in light of your recent changes to the name

@goal_rule

What's the right way to get a digest for some subset of files for which I have a directory digest? Specifically, I want just the content of

__init__.py

files , and I have a digest for all

.py

files

i ran into that yesterday, i was trying to extract a

PEX-INFO

file from a built pex in https://github.com/pantsbuild/pants/pull/8940. i ended up just calling

unzip -p

from the PATH (which doesn't work remotably). an executeprocessrequest that just runs

true

and specifies the desired output files could work in your case

That doesn't sound like what I want

```

I could use PathGlobs I suppose

do you not know the precise paths of the

__init__.py

files?

I do

I have the Snapshot

await Get[ExecuteProcessResult](ExecuteProcessRequest(
  argv=('true',), 
  input_files_digest=my_snapshot.directory_digest, 
  output_files=tuple(f for f in my_snapshot.files if os.path.basename(f) == '__init__.py'),
))

?

Seems like overkill

i agree

however, it does get persistently cached this way, which is nice

Seems like an odd thing to single out for persistent caching

No other filesystem monkeying is