Like, to correspond to

target()

in BUILD files? Yes, see

core/target_types.py

. If you mean a common class to inherit from, no. Targets no longer use inheritance in V2. Fields do, but every target should directly subclass

engine.Target

. (Nothing preventing this, beyond convention)

i am just trying to fill out

target_types()

to make the test pass

seems to work now. thanks a lot @hundreds-father-404!

@hundreds-breakfast-49010: if you have time to take a look at https://github.com/pantsbuild/pants/pull/9674 , it would be appreciated.

a bit left field, but: thoughts on changing the default “no specs” behavior to the equivalent of

--changed

(add adding a default value for

--changed-parent

presumably)

Hello, thoughts on this reorganization for

project-info

-y goals? In V2, these will be enabled by default, but be able to opted out of.

pants.project_info

(info on your own code): * list * filedeps * dependencies * dependees * cloc * roots

pants.pants_info

(info on Pants internals): * target-types * goals * options * backends

There is an issue w/ v2 UI on the latest release (1.28.0.dev1) and on latest master. if you press ^C while pants is running the process hangs forever and doesn't exist, the workaround is to

pkill -9

the process.

https://github.com/pantsbuild/pants/pull/8450 @hundreds-father-404 this PR will go green again in a bit, wanted to mention that upon merging this we might be able to kill

list_targets_old.py

entirely?

(Please do not merge that PR without re-reviews. Those reviews from October are stale.) We can’t kill

list_targets_old.py

until we require all plugin authors to write Target API bindings for their targets.

list_targets.py

fails to work with targets without bindings, whereas

list_targets_old.py

works with any V1 target. So, we need this until 1.30.x at the earliest, depending upon when we put out the deprecation warning that you need to write bindings.

Also bump on this https://pantsbuild.slack.com/archives/C0D7TNJHL/p1588298200450800?thread_ts=1588279608.441900&cid=C0D7TNJHL, and especially bump on the comment right below it about splitting this up into two PRs, if possible.

i wasn't going to merge it

Hey, we’ve had a couple users hit the “Too many open files” issue and today Benjy and I both hit it, even with

ulimit

configured. Do we know why we are opening so many file handles? I know

lmdb_store

uses a lot of handles, but are we expecting it to use thousands? A user last week hit it when running

./pants repl

with no targets, for example.

I find:

$ ./pants kill-pantsd && ./pants --enable-pantsd list 3rdparty/::
$ ps -ef | grep pantsd | grep -v grep
jsirois    77290     735  5 15:55 ?        00:00:03 pantsd [/home/jsirois/dev/pantsbuild/pants]
$ lsof -p 77290 | wc -l
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
      Output information may be incomplete.
386

So a fresh pantsd starts with ~400 open files. That presumably grows over time. Of those 386, most are lmdb:

$ lsof -p 77290 | grep .cache/pants/lmdb_store | wc -l
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
      Output information may be incomplete.
288

i believe that allocating too much shared memory also produces the same errno, and cannot be fixed except by restarting

i think that also can be rectified with

ulimit

, but a different incantation

only useful if the "too many file descriptors" hypothesis is found to be incorrect

what is your ulimit configured to?

20,000

and when you see this, please run

lsof -p $process

and add the output somewhere

I can’t reproduce, but good to know

… although i guess that’s more challenging because the process won’t stay up.

unless you use pantsd, as john demonstrated.

I don’t use pantsd generally

understood. we need to get it enabled by default, but it’s going to remain a bit awkward for @rule authors for a bit, because it needs a restart any time rules change.

(..for now. have plans to fix that.)

I wouldn’t optimize for rule authors yet. We’re close to opening up the rule and target APIs to end users, but that will still be alpha. Optimizing for every day users is far more important

right. but it stands in the way of truly dogfooding, and that’s a pain.

i’m not sure sure it’s reasonable to say “use pantsd unless you are editting rules”… but… that would be a thing

but also, there are some broken windows that i’m planning to fix this week.

Sure, but with dogfooding, it’s fine if our own dogfood has some rough edges. If we ourselves turn it off 40% of the time because we’re editing rules, we’re at least dogfooding it the 60% of the time