WTF IS WRONG WITH YOU TRAVIS???????

This is insane behavior

is it Travis or GitHub?

Presumably Travis

unknown... it looks like travis is grabbing:

From <https://github.com/pantsbuild/pants>
 * branch            refs/pull/7515/merge -> FETCH_HEAD
$ git checkout -qf FETCH_HEAD

so github is providing the divergent stuff, but travis isn't computing it once and then using it

"We rely on the merge commit that GitHub transparently creates between the changes in the source branch and the upstream branch the pull request is sent against."

This is just creating a race condition

this only makes sense in the context of a merge queue

New changes can always sneak into master between running CI and merging, so all this does is introduce uncertainty over what was tested, it in no way guarantees anything about the safety of merging to master.

Sigh

+1 to all of the above

devil's advocate: the shorter the gap between your merge base and master, the less risky the merge is. the fact that it is inconsistent between shards though is a much larger problem

https://github.com/pantsbuild/pants/pull/7515 @happy-kitchen-89482 just merged a pretty wicked contribution 👖 👖 👖

That was just my warmup lap for v2 rule contributions

speaking of which: https://github.com/pantsbuild/pants/pull/6880 is reviewable

Wait Travis does WHAT!?! Wow. That’s… Special.

turns out cffi will explicitly swallow any exceptions raised in python extern methods registered with

def_extern()

but it also turns out we can catch those and retrieve them later so we can have stacktraces on exceptions raised e.g. for unhashable type errors in the engine, and that's pretty neat: https://github.com/pantsbuild/pants/pull/7532

i'm now working on turning "swallowing fs errors" into "make a custom error enum and handle that" in https://github.com/pantsbuild/pants/pull/7551, this seems like a good refactoring to do anyway

i got this error after i first did

rm -rf /private/var/folders

since it said that was out of space, then i did

rm -rf ~/.cache/pants/lmdb_store

because it said that was out of space, now it still says that's out of space and it continues to make this error even after a `clean-all`:

Exception message: Build graph construction failed: ExecutionError 1 Exception encountered:
Computing Select(Specs(dependencies<Exactly(tuple)>=(SingleAddress(directory='tests/python/pants_test/backend/python/tasks', name='pytest_run'),), matcher<Exactly(SpecsMatcher)>=SpecsMatcher(tags<Exactly(tuple)>=(), exclude_patterns<Exactly(tuple)>=())), TransitiveHydratedTargets)
  Computing Task(transitive_hydrated_targets(), Specs(dependencies<Exactly(tuple)>=(SingleAddress(directory='tests/python/pants_test/backend/python/tasks', name='pytest_run'),), matcher<Exactly(SpecsMatcher)>=SpecsMatcher(tags<Exactly(tuple)>=(), exclude_patterns<Exactly(tuple)>=())), TransitiveHydratedTargets, true)
    Computing Task(addresses_from_address_families(), Specs(dependencies<Exactly(tuple)>=(SingleAddress(directory='tests/python/pants_test/backend/python/tasks', name='pytest_run'),), matcher<Exactly(SpecsMatcher)>=SpecsMatcher(tags<Exactly(tuple)>=(), exclude_patterns<Exactly(tuple)>=())), BuildFileAddresses, true)
      Computing Snapshot(PathGlobs(include=('tests/python/pants_test/backend/python/tasks/BUILD', 'tests/python/pants_test/backend/python/tasks/BUILD.*'), exclude=('.*/', '/dist/', 'bower_components/', 'node_modules/', '*.egg-info/'), glob_match_error_behavior<Exactly(GlobMatchErrorBehavior)>=GlobMatchErrorBehavior(value=ignore), conjunction<Exactly(GlobExpansionConjunction)>=GlobExpansionConjunction(value=any_match)))
        Computing DigestFile(File { path: "tests/python/pants_test/backend/python/tasks/BUILD", is_executable: false })
          Throw(Error making env for store at "/Users/dmcclanahan/.cache/pants/lmdb_store/files/6": No space left on device)
            Traceback (no traceback):
              <pants native internals>
            Exception: Error making env for store at "/Users/dmcclanahan/.cache/pants/lmdb_store/files/6": No space left on device

and i can probably figure this out but it is late and i want to put up this other change to pytest so just dumped it here in case this is a known issue

and fwiw, i have lots of free space and

touch /Users/dmcclanahan/.cache/pants/lmdb_store/files/6/wow

succeeds

https://docs.rs/auto_enums/0.5.5/auto_enums/ is pretty cool and could get rid of `BoxFuture`… I haven’t played with it, but it could be interesting… Probably not noticeably worthwhile (probably no perf bump or anything), but cute

interested in thoughts on how we can reasonably deprecate the behaviour that

./pants list

will "fully validate*" the graph that you run it on (*which is not quite true, but which is less true in v2 than in v1): https://github.com/pantsbuild/pants/pull/6880#discussion_r275732169

another use case for redirecting logging output: https://github.com/pantsbuild/pants/issues/7585

X-post from #pantsd -> Hi all, I am a dev at Foursquare and currently wrapping up a tooling project that serves dependency hygiene reports to our engineers whenever a PR is opened or updated for our mono repo. The basic idea is that we have a master report that is a json blob of all of our targets with a list of all dependencies and dependees for each target, and that report is updated for effected targets on a merge. The report is a generated diff from the PR's effected targets' dependencies/dependees and the master report. My question for this channel is

whether or not there is a way to opt out .pants.d/reports/ files being written when executing a given pants command

. For large PRs I am running the

dependee

commands in parallel, and sometimes it hits a

Exception message: Path for link would overwrite an existing directory: .pants.d/reports/latest

. I've looked through pants goals and didn't see anything to toggle off the reporting, so figured I would look for some guidance here :

cc @gentle-wolf-58752: ^?

@happy-kitchen-89482, @gentle-wolf-58752: a sketch of what i was suggesting you could do now, with minor changes to the engine (basically: just implementing #7490): https://gist.github.com/stuhood/10bed72e5dadf9fc36e9b9c96a8a230d ... we'd probably want some magic so that folks didn't need to manually create workunits, and instead had "named rules" or something, but.