@rhythmic-glass-66959, @curved-manchester-66006: hey folks! do you have some time to talk about https://github.com/pantsbuild/pants/issues/14395 ?

@bitter-ability-32190 https://pantsbuild.slack.com/archives/C046T6T9U/p1680111884221879?thread_ts=1680080947.835679&cid=C046T6T9U

runnable_dependencies

as implemented over in

adhoc_process_support

resolves the envvars needed to run a target; so the infrastructure for embedding a JVM is there in

runnable_dependencies

. Getting

runnable_dependencies

into more places would solve Tal’s problem

So, if I add a milestone to a PR, is that saying that it will need to be cherry-picked back to that version? I would love to see this one included in 2.16.x, so I added the

needs-cherrypick

label and the

2.16.x

milestone. Is that the right way to do that? Is this a good candidate for getting into 2.16.x? https://github.com/pantsbuild/pants/pull/18619

I was trying to take a stab at making the git sha/branch etc available to BUILD files as suggested at https://www.pantsbuild.org/docs/tagging-docker-images (I know about the spiffy

.pants.bootstrap

trick but though I would try anyway). I imagine to a user it would look like a handy object with properties for the sha, branch etc, and that it would make sense to leverage the existing

GitWorktree

I'm a little lost for what the 'shape' of this should be though with the existing precedents: • I don't think this is a new target or field... • I don't think it can be a

BuildFileAliases.object

(a "normal" python object) if it's going to reuse

GitWorktree

and it's engine integration •

ContextAwareObjectFactory

looked close but it's deprecated and/or there are zero left? •

ParseState

has some things like env() hard coded, but the necessity of that exceeded my ability to follow along

Would it make sense for tools to pull their default IC from the resolve when the user has set

[tool].install_from_resolve

? https://github.com/pantsbuild/pants/issues/15358#issuecomment-1491262069 The special tool IC handling seems to not work as well with

[tool].install_from_resolve

because you have to define the ICs for each resolve+lockfile instead of pants magically adding as many ICs as required for the tool. And, once you set the IC for the resolve, sometimes you have to overrides

[tool].interpreter_constraints

as well so that they agree with each other. So, I wonder what the best UX would be for IC definition across multiple resolves for both tools and user code. Maybe something along the lines of "named" configs: https://github.com/pantsbuild/pants/issues/12652 Thoughts?

I noticed that the pex builder seems to depend on the output filename (

<http://path.to|path.to>.some/target.pex

), which seems moderately unfortunate from a caching perspective. https://github.com/pantsbuild/pants/blob/1f4b040ba4e3e875d1b08c6c1d6bbbccc6538f0e/src/python/pants/backend/python/util_rules/pex.py#L572-L573 For instance: if a build target is renamed, or if multiple targets end up building the same PEX (e.g. multiple

include_sources=False

pexes that happen to have the same set of 3rd party requirements would be convenient to share from each other). Is that output path doing something other than moving the file around? As in, could it be fixed for the process invocation, and the renaming managed outside?

https://github.com/pantsbuild/pants/pull/18523 bump 🙂 Would like to know if the approach is sane or if I have to go back to the drawing board here.

I have release duty today. It looks like the following are on the docket in addition to the 2.17 dev release: + 2.14.2 final 2.14.2rc1 + 2.15.1rc1 + 2.16.0rc0

Could a github admin please delete my cherry-pick branches? I will push to my fork for future cherry picks. Sorry: https://github.com/pantsbuild/pants/branches • cherry-pick-18610-to-2.16.x • cherry-pick-18619-to-2.16.x

Please check my thinking on pants virtualenv exports and PEP 660 editable wheel installs: 🧵

Proposal: in 2.17.x we drop support for running pants itself on Python 3.7 and 3.8, and only support 3.9. Discussion in thread.

Does anyone have insight into why src/python/pants/core/goals/tailor_test.py::test_tailor_rule_write_mode is intermittently failing in CI like this: https://github.com/pantsbuild/pants/actions/runs/4585116571/jobs/8097072485

Hey @enough-analyst-54434, I'm interested in helping with Pex support for Windows. It blocks me using Pants in my day job because some contributors use Windows Where's that effort at / how could I help?

tests/python/pants_test/pantsd/pantsd_integration_test.py is a real problem, it fails frequently, but not consistently, in CI. And it doesn't appear to be related to system CPU load. E.g., here every other test is cached, and this one still fails.

I'm out this week, but I'll be back next week, and I'll do my best to chew through my 2.16 blockers

trying out 2.16.0rc0 and I’ve stumbled across something scary: https://github.com/pantsbuild/pants/issues/18662

WTF is "Forbidden skipped test"? We don't allow

pytest.mark.skip

?

Hi all, I realized I never added docs for the PEP 621

pyproject.toml

support, so I took a stab here: https://github.com/pantsbuild/pants/pull/18672 Thanks!

Can someone point me at the mechanism in the docker backend that auto-magically sets up dependencies? Is it this InferDeps? https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/docker/util_rules/dependencies.py Just wondering how we currently setup a dep in a Dockerfile, and Pants knows to build it. Looking at revisiting my Ansible plugin

Just confirming that we’re not doing any more 2.13 releases, right?

Funny thought: why is our dep parser internal? Why not publish it like another tool?

📣 Reminder to Pants Team members that our monthly meeting is coming up on Monday. Please send me agenda items by Thursday. As usual, the draft agenda is attached to your calendar invite. See you next week!

If we're packaging pex files and python interpreters using

scie

- is there a good reason to still have the

pex_binary.entry_point

populated? I know it's optional, but could that interfere with the scie config? e.g. After using PEX_TOOLS to unpack and compile our application - I'm running my binary like this.

"exe": "{scie.bindings.venv}/venv/bin/uvicorn",
              "args": [
                "apigateway.main:app"
              ]

Just wondering if I should keep my eye out for potential hiccups either at runtime, or in an upgrade workflow

I want to have a crack at extending the way

test

can collect additional stuff. Currently you can define

[test].extra_env_vars

to inject extra stuff into the env, and

runtime_package_dependencies

to add packageable targets to the test process digest. But from a quick skim of the code, all of this is replicated in each backends subprocess call. My thinking is to push it up a level so the

TestRequest

contains a

env_vars

and a

additional_digest

that the backend folds into its subprocess calls. Then

extra_env_vars

and

runtime_package_dependencies

could be implemented as Union rules, and other plugins can then set up prerequisites for tests as needed. ie. for my use case, I want to upload a target to a 3rd party and run integration tests against the remote resource. ... Is there a preferred process for going about making this sort of (large?) change?

chrisjrn@chrisjrns-MacBook-Pro pants % ./pants --keep-sandboxes=on_failure export-codegen src/rust/engine:compile_rust
09:42:54.04 [INFO] Preserving local process execution dir /private/var/folders/0m/h2n902qn38b8555xq8z0w_h40000gn/T/pants-sandbox-EdlSZp for Testing candidate for `python3` at `/Users/chrisjrn/.pyenv/shims/python3`
09:42:54.04 [INFO] Completed: Testing candidate for `python3` at `/Users/chrisjrn/.pyenv/shims/python3`
09:42:54.05 [INFO] Writing generated files to dist/codegen
chrisjrn@chrisjrns-MacBook-Pro pants % ls ./dist/codegen/src/rust/engine/target/debug
build           examples        libclient.d     libengine.d     pants
deps            incremental     libclient.rlib  libengine.dylib pants.d
chrisjrn@chrisjrns-MacBook-Pro pants %

👀

When building an external pants plugin - does Pants provide/expose a toml implementation that can be used?

For anyone who has interest - I'm working on a standalone plugin for

scie

creation (for Python, currently). ... Mostly because I'm manually creating these in one of my projects, and manual steps fly in the face of my sensibilities. https://github.com/sureshjoshi/pants-plugins/blob/83-scie/pants-plugins/experimental/scie/rules.py

pex_binary(
    name="hellotyper-pex",
    entry_point="hellotyper.main",
    dependencies=[":libhellotyper"],
)

scie_binary(
    name="hellotyper-scie",
    dependencies=[":hellotyper-pex"],
)

It's early days, need to pull a bunch of hardcoded stuff into the target's fieldset - and the goal here is not a comprehensive plugin, but rather a practical 80/20 one (e.g. can it create a standalone binary for CLIs and Application Servers is probably my target wheelhouse). Aiming to have

scie

binaries for all of the example python applications by tonight or tomorrow

Am I getting this

KeyError: <class 'pants.core.goals.deploy.DeployFieldSet'>

error because my project doesn't currently have any targets that use Deploy?

peekable_field_sets = [PackageFieldSet, TestFieldSet, DeployFieldSet]
        target_roots_to_field_sets_get = [Get(
            TargetRootsToFieldSets,
            TargetRootsToFieldSetsRequest(
                field_set_superclass=fs,
                goal_description="",
                no_applicable_targets_behavior=NoApplicableTargetsBehavior.ignore,
            ),
        ) for fs in peekable_field_sets]

Does scie-pants support

PANTS_SHA

-like behaviour, or do we need to use

PANTS_SOURCE

and a local source checkout?

I’ve got a change that makes pants do editable installs of all relevant `python_distribution`s when exporting a mutable virutalenv (which essentially turns pants into a PEP-660 frontend and backend - albeit delegating a few pieces of that to pip and to the configured PEP-517 backend). Or at least I’ve got all of the export tests passing now, including integration tests. I haven’t used this on the st2 repo yet 🙂 Scope of my change: This is only possible fore mutable venvs, so symlinked venvs will not get this feature. Tool resolves (which are deprecated in 2.16) do not ever have dists, so this does not apply there either. And I’m not touching the legacy export codepath (where you do

export <addresses>

) that will stay as is; this will only apply when using

export --resolve=

). So, here’s my question: Should we have a new export option to enable/disable editable installs? If so, should it default to enabled or disabled (disabled is the backwards compatible option)? Or should we always do editable install of dists when exporting a resolve that includes dists?