Is there a method to get multiple source roots for a file? It's a strange ask, but like, for a given file - can we enumerate all of the source roots from that file down to repo root?

hey folks! we’re past due for another

2.13.0

`rc`: does anyone have anything they’d like to get in?

hey folks! Me and Eric Arellano have worked on a blog post which is almost ready for publishing. If anyone has time to do a quick sanity scan, any comments would be very welcome! Many thanks https://docs.google.com/document/d/1T5BWB-NRZUode8zT4-oZg37WD1Ti8DB301ng-IebblY

Some annoyance that I’d love some help figuring out. As part of my PyOxidizer work, I need to replace instances where Pants uses

pkgutil.get_data

internally, because it’s not supported by PEP 304-style pluggable importers (PyOx…r uses one). The problem is that the replacement,

importlib.resources

, cannot currently load resources from namespace packages, and the very first thing that Pants does on startup is load the

VERSION

file from the

pants

namespace package using

get_data

. There’s a backport library that fixes this issue, but that would require users install an external requirement into their python environment. One option is to vendor the code in (it looks relatively small). Easier would be if I could move the

VERSION

file into a non-namespace package. It appears, though, that our installer script depends on the location of the

VERSION

file. I could leave the current version of the file as a symlink (or the importable version, for that matter). Do we have a preference here?

I was going to follow up today on the discussion two weeks ago about Pants being released with the last 3 released Python versions (3.8-3.10 for now). But now I'm not sure I should push that with @ancient-vegetable-10556's exciting Pyoxidizer progress?

Hey @fast-nail-55400, thanks for working on multiple go.mod support! https://github.com/pantsbuild/pants/pull/16386

https://pantsbuild.slack.com/archives/C046T6T9U/p1659560350697699?thread_ts=1658412143.380059&cid=C046T6T9U new thread to discuss API

Does anyone have pointers on where to look to add a Python interpreter? I've started a MicroPython project on the Raspberry Pi Pico - and I'm using pants for the formatting/linting, but would be nice to have that additional package step (though, it doesn't package to a pex)

(On 2.13.0rc0) Is it possible

paths

is broken? It seems to be outputting

[]

no matter what, even for trivial dep paths like direct dependencies

sh-5.1$ ./pants dependees //tests/sorted_components.py:../testlib
//:testlib
//tests/local/components.py:../../testlib
sh-5.1$ ./pants paths --paths-from=//tests/sorted_components.py:../testlib  --paths-to=//tests/local/components.py:../../testlib
[]sh-5.1$

@witty-crayon-22786 @enough-analyst-54434 (and others), thoughts on deprecating Poetry as a lockfile generator in 2.14, but with a longer deprecation cycle like don't remove till 2.16?

Related, @witty-crayon-22786 probably don't yet deprecate

[python].requirement_constraints

until we have landed local requirement support for Pex?

This is still somewhat experimental, but I now have a branch against 2.14 where you can build a standalone Pants binary using PyOxidizer: https://github.com/pantsbuild/pants/pull/16414 I believe everything in here should work as intended, and it successfully runs against our example repos. I haven’t looked at out-of-repo plugins just yet, and that’s likely to be somewhat gnarly, but if there’s other stuff that doesn’t work, I’d love to hear about it!

@enough-analyst-54434 before you head out, any thoughts if

--path-mappings

should be a global option vs. per-resolve for local requirements?

What's the case sensitivity policy with

expected_file_extensions

in a

SingleSourceField

? Does pants auto lower-case extensions when matching?

On my new M2 13" macbook pro (24 GB RAM, 8 cores) building the engine rust code takes a mere 3m30s!

Release prep: https://github.com/pantsbuild/pants/pull/16427

Apparently main got broken because https://github.com/pantsbuild/pants/pull/16415 was tagged skip-rust even though it was very much a rust change... Not sure how that happened? Either way, fix: https://github.com/pantsbuild/pants/pull/16428

Dev release question... (I pushed the wheels a couple of hours ago, in case waiting was needed) When I run

./build-support/bin/release.sh test-release

I'm told

Installed version of Pants (2.14.0.dev4+git165bb828) did not match requested version (2.14.0.dev4)!

When I run

PANTS_PEX_RELEASE=STABLE ./build-support/bin/release.sh build-universal-pex

I'm told:

ERROR: Could not find a version that satisfies the requirement pantsbuild.pants==2.14.0.dev4+git165bb828 (from versions: none)
ERROR: No matching distribution found for pantsbuild.pants==2.14.0.dev4+git165bb828

These seem... Conflicting? That one is stripping the git-sha where it shouldn't, and the other is requiring it where it doesn't see it?

Prep for 2.14.0.dev5: https://github.com/pantsbuild/pants/pull/16434 🙂

The next pile of fun for 2.14.0.dev5: https://github.com/pantsbuild/pants/pull/16436 😄

A while ago I accidentally pushed this branch, but GitHub think it's protected so I can't delete

I'll delete

Hm, I've been adding an option

[python].resolves_to_constraints_file

to let you hook up constraints files when generating a lockfile. Unlike before, this option lets you specify tool "resolves" like

pytest

and

black

in the

[python]

option. Whereas our conventional modeling would be

[black].constraints_file

and so on. Thoughts on what is preferable? This decision will apply to migrating

[python].only_binary

to be

[python].resolves_to_only_binary

When should I get hyped for

2.13.0rc1

?

Thinking about dissolving

update-build-files

, where should the plugin be located?

pants.backend.build_files

? (We have global options which use the term "build_file") We might able to do something a la: •

pants.backend.build_files.fmt.black

and

pants.backend.build_files.fmt.isort

? •

pants.backend.build_files.fix.upgrader

?

Does anyone recall why we don't use GitHub Actions' matrix strategy to build wheels for the different pythons orthogonally? Instead our jobs have a "primary Python" and then jump through hoops to expose the other Pythons on the path, and then build wheels for each python sequentially. We do invoke the matrix strategy, but we only pass it the "primary Python" as a singleton...

@witty-crayon-22786 for batched inference. What's be best way to measure the real-world performance? I know there's concern around cache invalidation when one file gets touched. I'm willing to test it on our work repo.

The per-resolve config project motivates fixing a problem we've had for a while:

[GLOBAL].plugins

and

[mypy].extra_type_stubs

don't currently give any mechanism to set a lockfile 🧵

FYI I'm seeing lots of timeouts for Python backend integration tests. They are resolving quickly for me locally, so I'm not sure what's up, e.g. something like rate limiting perhaps

In a bit of a transitive target API pickle here: If we have a field that can has an "impact" (side effect, I guess?) on transitive targets, where should that field be placed? I've run into these scenarios before, but can't find any examples, so I'll contrive a trivial, fake example while I try to find a precise use case from my archives: Let's say I have a compilation flag that could validly be different per target sources, BUT, when we want to link the compiled sources into a library object, the library requires that all dependencies have the same compiler flag. Is that something where we'd just expect the user to understand the language enough to reconcile that problem? Or would we try to solve it ourself? Or maybe this is where

defaults

or

overrides

come in?

# In order for check to pass, we need some special compile options
cc_sources(
    name="foo",
    compile_options=["magicoption1", "magicoption2"]
)

cc_sources(
    name="bar",
    compile_options=["magicoption2", "magicoption3"]
)

// In order for this library to be built, it requires a certain compile option in all deps
cc_library(
    dependencies=[":foo", ":bar"],
    compile_options??? overrides? 
)