looks like `target_option`s will always attempt to get resolved and the

Throw

is captured

@gentle-wolf-58752: there are some intentional negative lookups

to see whether optional tool definitions have been defined

would be good not to use exceptions for that, but: not a bug i don't think

(... danny said exactly this, sorry.)

👍 Got it, thanks for clarifying that @aloof-angle-91616 @witty-crayon-22786

spent several minutes playing around with converting BuildLocalPythonDistributions to a SimpleCodegenTask: https://github.com/pantsbuild/pants/issues/7129

there are multiple edits that would need to be made to SimpleCodegenTask and i was thinking if there is a candidate for v2 codegen this might be it

that being said, we don't really need "codegen" in v2

because we can just toss around whatever and have it dependency injected for free -- so maybe this is blocked on the python pipeline porting

but nothing else is blocking on this it was just for fun

also,

UnionRule()

appears to work and now has a much smaller diff with much fewer rust changes (mostly converting a couple `panic!()`s to `Result`s): https://github.com/pantsbuild/pants/pull/7116

to my infinite sadness, the UnionRule PR was green but i realized i left in a

native.py

change, so it's going through travis again, but it's solid i think

i also think removing

TypeConstraint

for

TypeId

in the engine will work now after making a very easy fix (which i'm extremely annoyed i didn't do much earlier): https://github.com/pantsbuild/pants/pull/7114, also waiting for travis

the PR to remove TypeConstraint from the engine and the one to add UnionRule are both green! was going to merge the UnionRule one tomorrow morning in case anyone wants to review it, the TypeConstraint removal one still needs review. not blocking anything else though so no rush

a v1/v2 engine overview we recorded last week: https://drive.google.com/file/d/1g1dqLXsTl7uMI-M7_1WFlkbbEoZbbNzx/view?usp=sharing : cc @happy-kitchen-89482, @gentle-wolf-58752

👋 Another question from an error I’m seeing locally - working on https://github.com/pantsbuild/pants/issues/7302 and debugging tests, I’ve run

./pants2 test tests/python/pants_test/build_graph:build_graph

on my branch and ran into what seems to be unrelated to my changes. When I switched to (the latest)

master

, the same issue persists when I run the same test command - this has happened before and a reboot resolved it, working on a Macbook Air (2018) on

10.14.3

with plenty of space available

self = <pants.engine.legacy.graph.LegacyBuildGraph object at 0x10e572f10>

                         @contextmanager
                         def _resolve_context(self):
                           try:
                             yield
                           except Exception as e:
                             raise AddressLookupError(
                     >         'Build graph construction failed: {} {}'.format(type(e).__name__, str(e))
                             )
                     E       AddressLookupError: Build graph construction failed: ExecutionError 1 Exception encountered:
                     E       Computing Select(Specs(dependencies<Exactly(tuple)>=(SingleAddress(directory=u'a', name=u'a'),), matcher<Exactly(SpecsMatcher)>=SpecsMatcher(tags<Exactly(tuple)>=(), exclude_patterns<Exactly(tuple)>=())), Exactly(TransitiveHydratedTargets))
                     E         Computing Task(transitive_hydrated_targets, Specs(dependencies<Exactly(tuple)>=(SingleAddress(directory=u'a', name=u'a'),), matcher<Exactly(SpecsMatcher)>=SpecsMatcher(tags<Exactly(tuple)>=(), exclude_patterns<Exactly(tuple)>=())), Exactly(TransitiveHydratedTargets), true)
                     E           Computing Task(addresses_from_address_families, Specs(dependencies<Exactly(tuple)>=(SingleAddress(directory=u'a', name=u'a'),), matcher<Exactly(SpecsMatcher)>=SpecsMatcher(tags<Exactly(tuple)>=(), exclude_patterns<Exactly(tuple)>=())), Exactly(BuildFileAddresses), true)
                     E             Computing Snapshot(PathGlobs(include=(u'a/BUILD', u'a/BUILD.*'), exclude=(), glob_match_error_behavior<Exactly(GlobMatchErrorBehavior)>=GlobMatchErrorBehavior(value=ignore), conjunction<Exactly(GlobExpansionConjunction)>=GlobExpansionConjunction(value=any_match)))
                     E               Computing DigestFile(File { path: "a/BUILD", is_executable: false })
                     E                 Throw(Error making env for store at "/private/var/folders/fv/9ly0y0dj1g946plb36nm4s1m0000gn/T/tmp24_0if/files/7": No space left on device)
                     E                   Traceback (no traceback):
                     E                     <pants native internals>
                     E                   Exception: Error making env for store at "/private/var/folders/fv/9ly0y0dj1g946plb36nm4s1m0000gn/T/tmp24_0if/files/7": No space left on device

                     .pants.d/pyprep/sources/e15daefeaae9c0ce65e78750d7c0f1a6079a5ee8/pants/engine/legacy/graph.py:238: AddressLookupError
                     = 5 failed, 14 passed, 3 skipped in 2.33 seconds =

If someone could take a quick look now - @gentle-wolf-58752 is holding off on rebooting his laptop so he can provide more debugging info if needed, but it means he's stuck.

Is this ringing any bells?

it looks like in the past i have literally run

rm -rf /private/var/folders/

to overcome this

i'm pretty sure this is what occurs when you create enough stuff in the temp dir and the os doesn't clean it up for whatever reason

hmmm

i am not sure if that will break anything

in solidarity i can run that command first

OK so time to google "expanding MacOS tmpdir"... 🙂

i ran it and there were lots of permissions errors, should have run

du -h /private/var/folders

first

but it maybe won't break anything immediately

and i would more google "cleanup macos tmpdir", since most of it is likely stuff that can be killed

found https://apple.stackexchange.com/questions/209266/el-capitan-private-var-folders-cache-files-consuming-30-40-gb

if the error continues to occur after you clean the tmp dir i would be surprised because that has fixed it for me before