i am not 100% sure, but it sounds like maybe https://github.com/rust-lang/rust/pull/72412 and https://github.com/rust-lang/rust/pull/76772 will fix some type length limit issues…?

Python question: is there a concise way to write a

with

block where the presence/absence of the

with

is controllable via a flag?

it is really confusing to reason about how signal handling works across pantsd and non-pantsd cases. I will be happy when we remove the signal-forwarding mechanism from how the client controls pantsd

it looks like if you use the

--logdir

option with pants, it prints every log line twice

I"m not sure why, I don't think it's a pansd thing

putting together https://github.com/pantsbuild/pants/pull/10835 made me realize that right now

./pants repl

is broken

because of signal handling in the pantsd case

even with the above PR, if you run

./pants repl

, then hit ctrl-c, some kind of python process will remain around and screwing up the terminal

Trying to understand how

python_library

/`python_tests` get resolved as we move our tests to v2 seeing an interesting issue when bringing in our common test utils

I'm closing https://github.com/pantsbuild/pants/pull/10830 and replacing it with https://github.com/pantsbuild/pants/pull/10845 since that's a cleaner way to solve the problem, thanks @witty-crayon-22786

Do y’all know why we use a

tool.pex

,

requirements.pex

, and

runner.pex

for things like Pytest? I think the

runner.pex

can be consolidated into the

tool.pex

. Iirc, it was to avoid having to recreate the

runner.pex

when you do something like bump a tool’s version. But that doesn’t seem like we save much; all the

runner.pex

ever does is set up an entry-point and

--pex-path

, which is trivial to do directly on the

tool.pex

in the first place.

A sequel to the thread above: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1600880758021500 Tests pass locally but are failing with no real output in CI/CD. When i try to run in container it produces the following rust backtrace

me and @hundreds-father-404 are considering the possibility that having

.*/

as a default ignore pattern in the

--build-ignore

and

--pants-ignore

might be undesirable

re: https://github.com/pantsbuild/pants/pull/10856#pullrequestreview-496040748 , is it okay to entirely remove all of these defaults options for --build-ignore ?

@hundreds-father-404: re: why

Specs

should probably not be a `SessionValue`: https://github.com/pantsbuild/pants/issues/6845 and https://github.com/pantsbuild/pants/blob/master/src/rust/engine/graph/README.md#inputs-and-identity attempt to explain the connection between identity and cacheability, but they don’t do a great job of it

I’m still getting an error with an undefined symbol for native_engine.so:

Compiling process_execution v0.0.1 (/data/home/tdyas/pants/src/rust/engine/process_execution)
   Compiling engine v0.0.1 (/data/home/tdyas/pants/src/rust/engine)
    Finished release [optimized + debuginfo] target(s) in 9m 25s
/data/home/tdyas/pants/src/python/pants/base/exception_sink.py:313: DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  process_title=setproctitle.getproctitle(),
/data/home/tdyas/pants/src/python/pants/engine/internals/native_engine.so: undefined symbol: PyModule_Create2TraceRefs
NoneType: None

any advice?

I wiped ~/.cache/pants and the venv, and still get this error

is there a reason why

with_executor

https://github.com/pantsbuild/pants/blob/master/src/rust/engine/src/externs/interface.rs#L1778` needs to take a

PyExecutor

and not a

&PyExecutor

?

there's this line

TODO: Use LMDB database statistics when lmdb-rs exposes them.

in the local store source above the

shrink()

method: https://github.com/pantsbuild/pants/blob/237e6a6e8b1c41d58a38426d92dac96f878f2159/src/rust/engine/fs/store/src/local.rs#L121, and in looking over that i found this

environment::Stat

object from the upstream lmdb-rs crate: https://github.com/danburkert/lmdb-rs/blob/12b4611006d5ba3bf80840faaa31a8b2e2bb6e88/src/environment.rs#L171. it's described as

Contains information about the size and layout of an LMDB environment.

. is that the info we would be looking for here?

also, it looks like we don't set the

digest_hint

in

PathGlobsAndRoot

anywhere. were we doing that manually in the parallel

RscCompile

task before? i'm looking to see whether we could support an optimization to avoid snapshotting process execution output files/directories that we already know about as per this comment on the mutable caches doc (which i didn't know was already implemented -- this is super awesome): https://docs.google.com/document/d/1n_MVVGjrkTKTPKHqRPlyfFzQyx2QioclMG_Q3DMUgYk/edit?disco=AAAAIva7gMw

will probably drop the above into issues EDIT: done

https://pantsbuild.slack.com/archives/C0D7TNJHL/p1601223189030500?thread_ts=1601218375.026600&cid=C0D7TNJHL just an idea

^stu had some great comments above, especially some very very interesting remarks on the mypy caching ticket: https://github.com/pantsbuild/pants/issues/10864#issuecomment-699689828. i'm putting the doc on hold for a bit until i can answer the questions raised, and i will take a look into

brfs

today i think as per the linked comment

I think a new dynamic UI bug, and it sounds like Benjy saw something similar today.

▶ ./pants test src/python/pants/backend/python/lint/docformatter/rules_integration_test.py -- -k type_stubs
⠉
⠉
⠉
⠉
⠉
⠉
12:21:21.38 [WARN] Completed: Run tests - src/python/pants/backend/python/lint/docformatter/rules_in
𐄂 src/python/pants/backend/python/lint/docformatter/rules_integration_test.py:integration failed.

Going from 120 pixels wide to 121 pixels wide in my terminal fixed it..?

did we have a reason for removing the

blocked

flag on

outer_metadata

in https://github.com/pantsbuild/pants/blob/master/src/rust/engine/process_execution/src/lib.rs#L491 ? @witty-crayon-22786 I think you might've touched this code?

@hundreds-father-404: re:

Starting

messages for test processes

anyone have any idea why https://github.com/pantsbuild/pants/pull/10873 is failing?

hey @hundreds-father-404 on this ticket I just want to make sure I understand it right. The current

python_app

target when using

bundle

it can get files from a different folder by using

rel_path

right? I mean, that’s basically what I’m doing… my BUILD file is inside

projects/projectA

and I need to have files under

libs/3rdparty/mydata

to be packaged together.

Experiencing an issue with pylint while running

./pants --no-v1 lint

in Pants 1.30.2rc0. Stack in thread

posting here because it proposes a change to the options system: https://github.com/pantsbuild/pants/issues/10885#issuecomment-701431374. basically, it seems like it might be good to allow users to configure environment variables that affect the tools pants invokes, but we generally run those tools with a stripped environment, so this normal method of configuration doesn't really work. particularly in the case of pex, we have to introduce pants options to cover each new pex option, which causes options fatigue as well as annoying variance in what's deprecated over time. i think we could introduce a

Subsystem

subclass

EnvironmentPropagator

which doesn't register any options itself, but allows environment variables in the form

PANTS_PEX_*

to be converted to just

PEX_*

environment variables when we go to run a process (where

PEX

is the value of a class-level string field

EnvironmentPropagator.environment_sub_component

. making this a subsystem (or not, and using some other method) means we could hook it up to

./pants help

and allow the user to see what variables are in their environment which would affect a pants execution, and we could also incorporate the tool's own help text for its environment variables. posting here because i made the comment specifically regarding using this for pex in the issue, and i want to see what response i get to that before trying to make a more general issue