need advice on a rule graph issue: https://github.com/pantsbuild/pants/pull/14432#issuecomment-1035273082 I need to add something but the error remains obtuse about what is missing

An offer via Twitter DM, from Eric Peters:

Do you guys use <https://github.com/pantsbuild/jarjar> (its archived now) I have some fixes, not sure if you need/would like them.

Thoughts?

Where did ARM-on-linux support land on the priority scale? And how can I help with that? Is it mostly just a matter of getting a builder instance in CI that can run the build?

it looks like someone forked 2.11 docs recently. How come? I'm actively updating 2.10 still, so that means now edits need to be copied to 2.11

I'm 🎣 for opinions on https://github.com/pantsbuild/pants/pull/14443 🧵 Tl;DR the

# delete me

comments in generated commits through the git hook

@fast-nail-55400 re Go version handling:

Looks like GitHub Actions has a 🐞 . The job is done, but is reporting that it is still running: https://github.com/pantsbuild/pants/runs/5159197493?check_suite_focus=true Therefore my PR is in limbo 😞 I'll re-kick and wait

Looking at https://www.pantsbuild.org/v2.10/docs/reference-experimental_shell_command I’m pondering if it wouldn’t make more sense to have a

shell_command

in a

pants.backend.experimental.shell

backend rather than a

experimental_shell_command

in

pants.backend.shell

… ?

hey devs. I can’t find if we already do this anywhere else in Pants. I have a list of files from

hydrated_sources.snapshot.files

. Now I’d like to copy them (while preserving the inner directory hierarchy) into a new, temporary directory that needs to exist on disk. I’ll need to pass that directory path to a binary tool. Can I access such a location in some temporary build directory somewhere?

howdy. I have a file produced in a build directory after running

Process

. There was a file produced. I need to rename that file.

files = await Get(DigestEntries, Digest, result.output_digest)  # result is from "await Get(ProcessResult, Process(...))"
    for file in files:
        print(f"Path: {file.path}")
        print(f"Path: {file.file_digest}")

get

stdout: "Path: file.data"
stdout: "\n"
stdout: "Path: FileDigest('a5958f492644f5abe6f784fb1840b70e279143cbbc5d3a0770d7554a8b80d982', 796)"

Reading https://www.pantsbuild.org/docs/rules-api-file-system#digestentries. Do I need to write the

FileDigest

on disk (to produce a brand new file) with

Workspace.write_digest()

or is there a mechanism to update the filename in place?

FYI: Danny thought we might be interested in this thread: https://twitter.com/sunshowers6/status/1493283867297337345?s=20&t=JowoHpvTHQ5Gk24X9tQVbg

@bitter-ability-32190 thoughts if we should document the new options system in 2.10 docs?

Rust Survey 2021 results: https://blog.rust-lang.org/2022/02/15/Rust-Survey-2021.html

Failing to lock

mypy

when adding a py3.7+ dep?

The current project's Python requirement (>=3.6)

I thought Pants was 3.7+?

(Somewhat of a small soapbox) So part of adding the new Options API was making sure we get the deduced property types right. No way to really test that in mypy. There's 3 tools in the wild that can help (https://pantsbuild.slack.com/archives/C0D7TNJHL/p1643838778597069) but they all invoke

mypy

in a subcprocess one way or another which doesn't work well in Pants' execution model. Turns out

pyright

(as of this year) and

pytype

have type assertions built-in, and it might make it into

typing_extensions

, but

mypy

is no-dice. So, I had some fun and decided to hack it in

mypy

through a plugin. Introducing my first and only PyPI package:

mypy-typing-asserts

https://github.com/thejcannon/mypy-typing-asserts And the resulting Pants PR (where the plugin found several issues 😈 ) https://github.com/pantsbuild/pants/pull/14527

Once the PR lands, feel free to add more type assertions, if you're worried about the deduced type of "things"! 🙌

@wide-midnight-78598 If you're looking for extra credit 😉 want to take a stab at pyoxidizing Pants itself? Being able to deploy Pants as a true standalone binary would be huge.

I've been looking at it 🙂 I saw that John had an update here too that used PyOx, but I hadn't read into it yet https://github.com/pantsbuild/pants/issues/7369#issuecomment-1043486639

You might want to see the latest comment on the issue. I may be an outlier, but pyoxidization fails for me (the current unit tests) because my Linux has too new glibc that removes the deprecated since 2017 libcrypt.so.1 in favor of a 4 going on 5 year replacement.

So, not sure about the strategy in general in light of this.

@wide-midnight-78598 coke

Greg's linked issue is better to read than mine. This is a wider problem and he's bugged RedHat.

So I do think pyoxidization is likely a medium term no go.

Arch may be niche but RedHat not so much.

Correct me if I'm wrong, but couldn't users self-select standalone vs bootstrapped and have Pants provide both until the standalone works across the board?

If I didn't have the linked issue, I'd love to use a standalone Pants 🤓

brew install pants

is where I'd like to get

Well... I still want the bootstrapping based on the version. It's the same thing Bazelisk provides for Bazel. Upgrading Pants versions isn't free, and have your app manager hound you with "a new version is available" is annoying and borderline dangerous 🙂

Yeah, definitely tricky. But may be worth doing with the caveat that you may have to fall back to bootstrapped depending on your system conditions (which we can detect).