Hey - I'm trying to get a build working on ARM-64. I've successfully compiled pants and the build starts but I have a step that runs

protoc

via the standard pants

protobuf_library

goal. If I run the build with

--no-process-execution-local-cleanup

I can cd into the directory and if I try to run the command I get

bash: ./bin/protoc: cannot execute binary file: Exec format error

. Indeed, if I just run

./bin/protoc

I get that error. However, I have

protoc

installed so if I change the command to run just

protoc

instead of the

./bin/protoc

in the sandbox it works. I think the issue is that pants seems have bundled their own protobuf compiler and it's an intel build, not an ARM build. Is that correct? Any way I can fix that?

Hi! What Pants version? macOS or Linux?

2.6.0 Linux.

Hmm, I'm surprised it doesn't error on not finding an appropriate entry in this option: https://www.pantsbuild.org/docs/reference-protoc#section-known-versions

Hmm @witty-crayon-22786 I had thought you added to the docs about hosting binaries from local filesystem path, but I don't see it on https://www.pantsbuild.org/docs/proxies#hosting-binaries? Even though Pants doesn't yet support ARM, I think you can "trick it" by pointing to your local binary. Also see https://github.com/pantsbuild/pants/pull/12879, a user started to add ARM64 support but didn't finish

@hundreds-father-404 so if I upgrade to 2.7 you think I'll be OK?

Hmm @witty-crayon-22786 I had thought you added to the docs about hosting binaries from local filesystem path

mm… no: it’s only mentioned in the subsystem help.

(about to head to a meeting; back online in 30)

Ah! So I guess you need to upgrade to 2.7, and then set something like this in pants.toml:

[protoc]
known_versions.add=["3.11.4|linux_arm64 |<sha256 of relevant protoc binary>"]

And that'd work on both intel and ARM or would my build then only work on ARM (I need both)

2.7 wouldn't work because you're on Linux, not macOS. In fact, Benjy, I think using 2.7 might cause an error because

Platform

does not include Linux ARM 64 in it? I think we may need to cherry-pick to Pants 2.7 that you can attempt to use ARM Linux, only you will have to host the binaries yourself 2.6 won't work if you need to support both Intel and ARM. It would make you choose one. (Which you could override in a

.pantsrc

config file fwit)

In principle that adds the value to the existing default, which includes linux_x86_64, so should work on both

OK. It'd be nice to have full ARM support. For now the targets that we need to build for ARM don't actually need protobufs (I think) so I think I have a super-hacky workaround.

Disable a goal, or a target?

Target

You can tag targets (

tags=["arm64_only"]

for example) and then include or exclude tags at runtime, e.g.,

./pants --tag=arm64_only ...

or

./pants --tag=-arm64_onlu ...

)

@happy-kitchen-89482 would

platforms

work? e.g.

python_library(
   platforms = [
      'linux-x86_64-cp-37-m',
      'macosx-11.0-x86_64-cp-37-m'
   ]
)

Ah no, that is not a thing

I see. Tags aren't working for me either. The issue is that I have a 3rd party library that doesn't exist for ARM. But I don't need the library and pex that uses it. So I tagged those targets with

noarm

and then ran

pants --tag='-noarm'

but pants still tries to install everything in

constraints.txt

even if no target to be built actually needs that dependency. So it fails installing a library I don't need. But I do need/want those targets on Intel and I want them pinned so I don't want to remove them from my constraints. What to do?

For that, we need multiple user lockfiles I fear: https://github.com/pantsbuild/pants/issues/12314 Which we made a lot of progress towards doing last month. But blocked by some work John has been doing for Pex to generate lockfiles using pip, which has been his top priority @witty-crayon-22786 do you know of any workarounds here?

FWIW, I've found

pip-compile

generates a much nicer lockfile that pip. Mostly I like the comments it puts under each dependency saying where it came from and the fact that it only locks what's in the file you pass it (e.g.

<http://requirements.in|requirements.in>

) rather than locking everything in the venv.

yea: see https://www.pantsbuild.org/docs/reference-python-setup#section-resolve-all-constraints … the default is an optimization that assumes that your cache will be reused

thanks @witty-crayon-22786. That makes sense. Per the above the issue I'm having is that it's trying to resolve constraints that don't exist for ARM64 and we're never going to build those targets on ARM. Short term it seems like pass the

--no-python-setup-resolve-all-constraints

might make things work though at the cost of some speed. Sound right?

yes, that’s correct: BUT, i think that that is also something that is addressed in 2.7, if I remember correctly… when platforms are in use, the optimization is disabled

From my point of view the ideal would be the ability to disable targets for various reasons. CPU arch is the current constraint but, IMHO, a general

if

statement that could use other constraints (e.g. OS, an env variable, etc.) seems pretty valuable. I do understand that you'd have to limit what could be there to make builds reproducible (e.g. env vars are harder but you do already allow that for tests).

Eric is also right that disabling this optimization is temporary until we’ve implemented multiple user lockfiles, as that would support both resolving the constraints file, and multiple platforms. trying to find the relevant ticket there

that is also something that is addressed in 2.7, if I remember correctly… when platforms are in use, the optimization is disabled

@witty-crayon-22786 I'm up for upgrading to 2.7 but if I followed the conversation above it sounds like that won't yet work on ARM+Linux at all (see https://pantsbuild.slack.com/archives/C046T6T9U/p1634153982080700?thread_ts=1634151679.077600&cid=C046T6T9U)

there is another ticket that would confirm that we disable this optimization automatically in 2.7. but yea, moot until you’re able to upgrade there.

That would be this I think: https://github.com/pantsbuild/pants/issues/12612

Still having issues. I think the issue that remains is that if you use

--tag

with a

::

target it first builds the .pex files for all targets, even those excluded by the

--tag

and then filters by tag so there isn't an easy way to say "run all tests except those with tag X and don't bother resolving dependencies for the tests you won't run". For example, with

-ldebug

I see:

02:16:11.58 [DEBUG] Completed: Hit local cache: Scheduling: Determine Python imports for realsense/lib/colorize_depth.py

and then the old error:

ERROR: Could not find a version that satisfies the requirement pyrealsense2==2.49.0+companion3
ERROR: No matching distribution found for pyrealsense2==2.49.0+companion3

But that target looks like this:

cpy_library(
   tags=['noarm']
)

cpy_tests(
   tags=['noarm']
)

Where the definitions of the

cpy_

macros is:

def cpy_library(**kwargs):
    python_library(**kwargs)

def cpy_tests(**kwargs):
    if 'name' not in kwargs:
        kwargs['name'] = 'tests'
    python_tests(**kwargs)

and the command I ran is:

pants --tag='-firebase_emulator,-noarm' --no-python-setup-resolve-all-constraints -ldebug test ::

You would need to set LDFLAGS appropriately I think... away from my computer, but there should be some hits on the docsite

Still having issues. I think the issue that remains is that if you use 

--tag

 with a 

::

 target it first builds the .pex files for all targets, even those excluded by the 

--tag

 and then filters by tag so there isn't an easy way to say "run all tests except those with tag X and don't bother resolving dependencies for the tests you won't run".

That seems odd.

Well that’s a gotcha.. I too would’ve expected the

-

to be on a per tag basis..

it's the same code as `filter`: https://www.pantsbuild.org/docs/project-introspection#filter---find-targets-that-match-a-predicate we probably need more examples there

Ah, right. It is this:

You can prefix the filter with 

-

 to negate the filter, meaning that the target must not be true for the filter.

That causes the confusion for me.

Yup it was the double

-

in the filter that confused me. Sorry for the false alarm.