there should be a better way for unix systems to map the command you type at teh command line to a specific fully-qualified binary name

classpath is also bad, logging libraries that configure themselves based on classpath ordering are the worst

do you know if @witty-crayon-22786’s proposed changes to how we build the FFI will affect

engine_cffi/build.rs

?

i should check that out to know the answer to that question

hm, I kinda want to not even limit this to os x

i agree, but i don't think the location of

ar

is as standard on linux distros

will

/usr/bin/env ar

always work?

we do actually provide an

ar

via binutils, which we have in the pantsbuild s3 as a binary tool

no,

/usr/bin/env

just resolves from the PATH, which is the default behavior of the

cc

crate

also, separately, i'm making a version of

process_executor

that expands the API to support splitting inputs across parallel process invocations, and also to support registering a daemon execution (e.g. "start up a nailgun"). the upstream remote execution API has some thoughts about this but this

process_executor

is specifically tuned to invoke processes on the local machine (current MVP: compiling scrooge code to scala extremely fast by using shared memory). i think i can have a prototype to kick around this weekend, have spent a bit of time on this already so it's not out of nowhere. this is something i hope to be working on for twitter soon

another thing i wanted to raise from the thread with greg just now: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1588233857430000?thread_ts=1588233213.419300&cid=C0D7TNJHL

if we arrange rust cargo targets in the same directories in the process execution chroot as they are in the buildroot, no changes are required to make cargo projects with pants

i actually first implemented that part by accident and cannot claim to have thought of it so i just wanted to make sure others were aware

why might i be getting this error message when trying to test

list-v2

?

pants.base.exceptions.TargetDefinitionException: Invalid target a:a: Target type 'java_library' is not recognized. All valid target types: [].

when i run tests for https://github.com/pantsbuild/pants/pull/8450 locally

the file clearly adds:

@classmethod
    def alias_groups(cls):
        return BuildFileAliases(
            targets={
                "target": Target,
                "java_library": JavaLibrary,
                "python_library": PythonLibrary,
            },
            objects={
                "pants": lambda x: x,
                "artifact": Artifact,
                "scala_artifact": ScalaArtifact,
                "public": Repository(
                    name="public", url="<http://maven.example.com>", push_db_basedir="/tmp"
                ),
            },
        )

hm. the test fails locally for

list_targets_old.py

as well. not sure why, let's see if i've broken something elsewhere

to be clear, it works on master, so i doubt a CI run will pass. not sure yet i could have broken this from that PR though (but it's definitely this PR, master is fine)

list-v2

requires a target API binding for it, meaning it’s registered via the entry point

def target_types()

. In contrast,

list

uses TargetAdaptors

Have you pulled master recently? That is an old exception message for unrecognized targets iirc

Also,

list_targets_old.py

is going away once TargetAdaptors go away. For that PR, you’d want to update

list_targets.py

. You could backport it to

list_targets_old.py

if you want, too, but the important one to update is

list_targets.py

I’m not sure how the hash will work with the Target API. Do those concepts still make sense for

intransitive_fingerprint_arg

and

transitive_fingerprint_arg

?

i have pulled master recently, i rebased when i messaged earlier

the hash is intended for consumption by external tools, which we don't have an analogue for yet, so i think they do make sense

this PR is using

list-v2

, by the way. it wasn't incredibly difficult to update. i wish i hadn't gotten so much pushback about this PR earlier, or it would have already gone in and this rebase wouldn't have needed to happen.

what is the target API binding for BUILD file objects?

TypeError: Every element of the entrypoint `targets` must be a subclass of Target. Bad elements: [<class 'pants.build_graph.target.Target'>, <class 'pants.backend.jvm.targets.java_library.JavaLibrary'>, <class 'pants.backend.python.targets.python_library.PythonLibrary'>].

figuring it out

figured it out

i'm also pretty sure

description

is a field that should be added to every target. this wasn't clear before porting the testing to use list-v2

description

is included in

engine.target.COMMON_TARGET_FIELDS

. Every target defined in

pantsbuild.pants

does should have it

ok, is there a

TargetTarget

type then?