#22797 Update default NodeJS and Package Managers Issue created by sureshjoshi We're still rocking Node 22 and the package managers have all had a major bump. pantsbuild/pants

#22086 Add a stalebot Issue created by sureshjoshi pantsbuild/pants

#22534 Update default pytest subsystem version to 8.x Issue created by zach-overflow ## Motivation • At the time of writing this, pytest's current stable release is at `8.4.1`, but Pants still defaults to

7.0.1

. • There are lots of feature additions and bug improvements between pytest

7.0.1

and

8.4.1

. At least in my case, many of the desired features translate to much broader pytest configuration control centralized in my codebase's

pyproject.toml

. • Moving to pytest 8.x would also mitigate a number of deprecation warnings that stem from older versions of pytest (see related issue thread here for one such example impacting us at the moment). ## Solution Description • Bump the default version of pytest to

8.x

. ## Alternatives Considered • Modify the pytest version in our project. Not totally opposed to this, but I wanted to see if there's any reason not to bump the version at the source. pantsbuild/pants

#22803 Dependabot `reviewers` has been removed in favour of code owners Issue created by sureshjoshi https://github.blog/changelog/2025-04-29-dependabot-reviewers-configuration-option-being-replaced-by-code-owners/ Should remove the reviewers from our Dependabot file, and (maybe) add a code owners. pantsbuild/pants

#22479 macos-13 Github Runners will stop working on November 14, 2025 Issue created by sureshjoshi https://github.blog/changelog/2025-07-11-upcoming-changes-to-macos-hosted-runners-macos-latest-migration-and-xcode-support-policy-updates/

macos-13 is closing down

The macOS 13 hosted runner image is closing down, following our N-1 OS support policy. This process will begin September 1, 2025, and the image will be fully retired on November 14, 2025. We recommend updating workflows to use macos-14 or macos-15.

pantsbuild/pants

#22807 Extract all JS/TS test code to resources Issue created by sureshjoshi It's very difficult to update as a mish-mash of some lockfiles, some inline lockfiles, some package.jsons, some inline package.json files I have 2 test failures after updating PNPM related to workspaces, but because I can't "just run" pnpm on the system to update or migrate, debugging these tasks is a chore. Ideally we could share the resources between those two backends too, but that's less important. The files themselves look like they were created and then inlined. A nice cherry on top would be a python/bash file that would auto-run all associated updates. pantsbuild/pants

#22813 Select for properties of targets such as version in pants queries/filters Issue created by dannytodd Describe the solution you'd like I would like to be able to query, via pants, properties of targets rather than simply the targets (and their transitive dependencies) themselves. Namely, the

version

parameter of all targets that support it. This would enable triggering of release builds of packages when a version bump occurs by querying with something akin to: pants list --filter-target-type=python_distribution --changed-property=version This is a common pattern when dealing with file-level changes in other systems, such as triggering on changes to a

__version__

file. The added granularity of being able to handle target properties directly would be useful in lots of cases, but triggering on version updates would be a good first example. Describe alternatives you've considered The basic alternative would be to grep the git diff of BUILD files, but this isn't very robust. pantsbuild/pants

#22814 Explorer plugin seems to be incomplete Issue created by sureshjoshi @kaos Do you recall where this left off? I noticed during some dependency updates that there is no frontend ui other than what graphql provides. My thought was to remove this backend and try to pull it into an external plugin (or merge it in the Suspenders vscode plugin. pantsbuild/pants

#22824 2.30.0 release management Issue created by cburroughs 2.30.0 will be the next 'major', following 2.29 on 2025-10-04 2.29 branched in 2025-W37; 6 weeks after that is 2025-W43 aka the week of 2025-10-20 • Create Milestone • Bug Triage! • Prepare Release Notes • Blog Post • Additional RCs as needed; nudge testing in productive testing; various applications of human judgement under conditions of uncertainty. • Actually do the release! • Update Example Repos • Update schema store (https://www.pantsbuild.org/prerelease/docs/contributions/releases/release-process#step-5-publish-a-schema-in-json-schema-store) • Ensure there's a "2.31.0 release management issue" like this one, for the next release pantsbuild/pants

#22608 2.29.0 release management Issue created by cburroughs 2.28.0 will be the next 'major', following 2.28 on 2025-09-08 • 2.28 branched on 2025-07-02; 6 weeks after that is 2025-08-13 • 6 weeks after 2025-09-08 is 2025-10-20 • Bug Triage! • Prepare Release Notes • Blog Post • Additional RCs as needed; nudge testing in productive testing; various applications of human judgement under conditions of uncertainty. • Actually do the release! • Update Example Repos • Update schema store (https://www.pantsbuild.org/prerelease/docs/contributions/releases/release-process#step-5-publish-a-schema-in-json-schema-store) • Ensure there's a "2.30.0 release management issue" like this one, for the next release pantsbuild/pants

#14639 pyoxidizer_binary should accept a fully qualified module + function as an entry_point Issue created by sureshjoshi At the moment, the configuration only supports a

run_module

field (as though run with

python -m myproject.myapp

), but it should be trivial to extend that to running a specific function on binary launch (similar to .pex files). It should be a relatively easy fix, and keeps a nice visual consistency with the

entry_point

of the

pex_binary

I only noted that I forgot to support this case while writing the documentation pantsbuild/pants

#14734 [PyOxidizer] Expose `default_python_distribution` Issue created by sureshjoshi https://pyoxidizer.readthedocs.io/en/stable/pyoxidizer_config_type_python_distribution.html#starlark_pyoxidizer.default_python_distribution https://pyoxidizer.readthedocs.io/en/stable/pyoxidizer_history.html#new-features This should be a first-class option, either target-level or globally, but we should be able to specify directly which pyox we use in lieu of requiring a template. Edit on Nov 4th, 2022: • Need to align PyOx distribution with interpreter constraints • How will a custom PyOx config play nicely with the interpreter constraints • Does PyOx download the Python version, or does it need system ones for any reason? It should be downloading something, as PyOx uses custom Python dists pantsbuild/pants

#18591 Expose in `peek` which goals are associated with a target Issue created by sureshjoshi This was a conversation in Slack, but the long and short of it is that there isn't really a "good" way to say "find all targets that are `test`able" or "list all `package`able targets". This functionality is used by the Pants engine and can be unreliably logged to the console, but this would be nice to have as a first party command of some sort (part of

peek

, a

list

filter, a new goal shudder). Example as a filter:

pants --filter-goal-type=test list ::

Alternatively, maybe this functionality should be part of a BSP? Unsure. ### Example of logging to the console: oss/pants-plugins % pants list package 141346.36 [INFO] Initialization options changed: reinitializing scheduler... 141347.06 [INFO] Scheduler initialized. 141347.09 [WARN] No targets were matched in goal

list

. 141347.09 [WARN] No files or targets specified. The

package

goal works with these target types: * archive * pex_binary * pyoxidizer_binary * python_distribution Please specify relevant file and/or target arguments. Run

pants --filter-target-type=archive,pex_binary,pyoxidizer_binary,python_distribution list ::

to find all applicable targets in your project, or run

pants --filter-target-type=archive,pex_binary,pyoxidizer_binary,python_distribution filedeps ::

to find all applicable files. ⏺️ oss/pants-plugins % pants list :: pants-plugins/experimental/swift/util_rules:util_rules ... ... ... pants-plugins/experimental/swift/util_rules/compile.py ⏺️ oss/pants-plugins % pants list package 141402.99 [WARN] No targets were matched in goal

list

. Note that the second call to

list package

doesn't show the same warning as the first call. pantsbuild/pants

#15452 Github CI should fail early on modified code/failing tests Issue created by sureshjoshi Per the Slack chat (https://pantsbuild.slack.com/archives/C0D7TNJHL/p1652363391676529)

I'm sure this has been discussed a bunch, but is there any way to "speed up" the PR CI testing, or at least, short-circuit some of it? I'm adding a pretty isolated formatting plugin, but the testing is still around 50 minutes for a test failure which didn't show up on my local machine (for some reason, not sure why it passed locally).

Is the pants dependency inference good enough that a simple ./pants --changed-since=... test would be safe for the PR?

If not, maybe run that test before running the whole suite? That way, if any of the modified code is breaking, CI will fail fast? And if not, we just fallback to a regular full test suite (with the modified code test results memoized)?

The summary of the chat is that it might be worth having a sanity test before running the test suite, which would probably fail within a few minutes, if it is going to fail on newly PR'd code. ./pants --changed-since=origin/main test # followed by ./pants test --shard=... :: pantsbuild/pants

#16835 cgo: use `-trimpath` option to `go tool cgo` to remove sandbox prefix from paths Issue created by tdyas Make use of the

-trimpath

option to

go tool cgo

to remove sandbox prefix from source paths. This will involve using

__PANTS_SANDBOX_ROOT__

replacement support of

GoSdkProcess

. pantsbuild/pants

#18100 PyOxidizer ignored python.pip_version Issue created by cburroughs Describe the bug Some config sippets

[python]
pip_version = "22.3"

[pyoxidizer]
interpreter_constraints = ["CPython==3.9.*"]

But when I poke in the sandbox I see

$ /tmp/pants-sandbox-xKFXVz/.cache/pyoxidizer/python_distributions/python.1c490d71269e/python/install/bin/python3.9 -m pip --version
pip 21.2.4 from /tmp/pants-sandbox-xKFXVz/.cache/pyoxidizer/python_distributions/python.1c490d71269e/python/install/lib/python3.9/site-packages/pip (python 3.9)

Pants version 2.16.0.dev5 OS Linux Additional info I tripped on this because after it was running for ~20 minutes (which is probably longer than it takes to compile CPython) so I decided to figure our what

./pants package

was doing, and it turned out to be

pip

pegging a core:

ecsb     17442 94.3  0.3 138260 121068 ?       R    09:30  30:52 /tmp/pants-sandbox-xKFXVz/.cache/pyoxidizer/python_distributions/python.1c490d71269e/python/install/bin/python3.9 -m pip --disable-pip-version-check install --target /tmp/pyoxidizer-pip-installXrTk0h/install feast_demo-0.0.1-py3-none-any.whl

My naive expectation was that the

python.pip_version

setting would be used. I suppose there might be a case where a

pyoxidizer.pip_version

settings might be needed. Presumably tangled up with #14619 and #14734 pantsbuild/pants

#19599 Create a benchmark repository that reproduces performance issues Issue created by jriddy ## Problem I, as well, as many users reporting in Slack, struggle with poor performance of Pants when performing core features like dependency resolution or inference. However, the repos the reproduce these issues are usually private corporate repos whose contents cannot be shared outside their owning organizations. In order to solve these issues in Pants open source, we need to be able to reliably reproduce them. ## Problem We need a complicated, convoluted monorepo that replicates the performance issues we're seeing, so we can use this to run benchmarks with different versions, to keep us from stabbing in the dark with optimizations. ## Alternatives • Tailoring an open-source Python repo • Converting an open-source Bazel repo to Pants • Generating one • Anonymizing a corporate repo ## Criteria • Running

pants peek ::

on the repo should take on the order of ~60 sec with no memoization and a warm cache. • Running

pants dependencies ::

should consume approaching 4 GiB of memory pantsbuild/pants

#19552 Provide way to infer deps from environment-provided dependencies Issue created by jriddy Is your feature request related to a problem? Please describe. The Pants Python backend doesn't currently only provides ways to deal with dependencies that come from first-party in-repo code, or third-party code via the Pip/PyPI ecosystem. However there are many valid ways of running and using Python code that involve dependencies being provided by systems outside this ecosystem. Some (non-hypotheitical) examples include: • Dependencies provided by system packages such as DEB or RPM packages • Dependencies provided by a deployment runtime, such as implicit Lambda layers as seen in #19256 • Dependencies provided via Conda These are all actual known use cases. It's also easy to imagine that proprietary on nonstandard code might be distributed via ad-hoc mechanisms as well, but I don't know of any specific outstanding requests for dealing with this (although I have seen this in the past with vendor-provided drivers and bindings). Right now, there's simply no way to reference these kinds of dependencies within Pants. Existing workarounds are to either manually map an environments dependencies to (close) Pip-based equivalents, to use no-infer-dep pragmas to hide these deps, or to simply lie to Pants and create false dependencies that represent code we can't actually resolve, and just avoid trying to package these deps via some kinda transitive exclude. All of these are hacky and annoying. Describe the solution you'd like We could provide a union rule for Python dep inference that allows us to model other kinds of third-party dependencies (fourth party dependencies? 😁). I suggested this in a Slack thread, and it didn't receive any major objection. The current module mapping mechanism hard codes the two paths but this could be extended to be a union membership, similar to the Go implementation or even the Python first party implementation. The goal here would be to leave this open ended to let other rules provide their own implementation of a module->target mapping as they see fit, and in so doing, reify those external dependencies for Pants in some way. Describe alternatives you've considered The main alternatives are listed above: you have to hack around Pants to do this. This is okay for some one-off cases, but it quickly gets unwieldy. Additional context Deferring dependencies to the environment almost necessarily breaks Pants' guarantees around hermeticism and reproducibility. I'm not proposing any particular way to deal with this for this issue, because it really depends on the provider of the dependency how this could be accomplished. This probably needs to be documented clearly somehow for consumers of this union rule, so any accompanying docs should state this clearly. There's also an issue of interpreter constraints. System provided dependencies are unlikely to apply to more than one interpreter, and may only make sense when using a particular interpreter, even of the same version, since site configurations will vary between interpreters and thus the nature of the builtin module search path and import hooks. I'm not sure how much interpreter selection should fall into this issue, but it's certainly a complicating factor, and we should probably at least research how this will play out. Lastly, it may not be possible to use any of these dependencies with any of the default implementations of Python goals without making PEX more capable of excluding dependencies in a fine grained way as described in pex-tool/pex#2097 pantsbuild/pants

#20071 Pants' filesystem watching build invalidation should only be sensitive to paths being depended on Issue created by kuza55 Is your feature request related to a problem? Please describe. It would be better if pants did not restart builds when files unrelated to the current build were modified. Describe the solution you'd like I'd like pants to build a map of the paths it depends on, and for the filesystem watcher to only restart the build when one of those paths is modified, rather than when any file in the repo is modified. Describe alternatives you've considered I'm investigating disabling the filesystem watcher for building docker containers to alleviate the pain of any change during a 30 min build restarting the whole thing, but this is a bit of a kludgy solution. pantsbuild/pants

#22838 WARN if local_execution_root_dir is not on the same file system as cache directories Issue created by cburroughs Currently if these are on different file systems, everything will appear to work fine on small projects or examples, but: • Performance will be bad because one can not hardlink (among other possible optimizations) across file systems • If

/tmp

is

tmpfs

(aka just in memory) Pants sandboxes will quickly fill it up. It is totally reasonable (ex from slack: https://pantsbuild.slack.com/archives/C046T6T9U/p1694679410518159) for people to not be familiar with the details of their CI filesystem layout, so even if this "works" on their workstation, they get bitten with spooky CI problems. We can steer away from this unlikely-to-be-what-you-want configuration by issuing a WARNing on startup. pantsbuild/pants

#22574 Allow setting Python resolve `interpreter_constraints` as defaults for targets Issue created by ndellosa95 Is your feature request related to a problem? Please describe. Most Python targets have separate

interpreter_constraints

and

resolve

fields. Resolves themselves also have interpreter constraints set in

pants.toml

. By default, the

interpreter_constraints

on Python targets defaults to the

[python].interpreter_constraints

field in

pants.toml

. However, if you have multiple resolves with different interpreter constraints, you now have to set the interpreter constraints on each Python source file to be a subset of the constraints of its resolve. Describe the solution you'd like There should be an option in the Python subsystem to allow Python targets with a

resolves

field to fall back to the interpreter constraints of their resolve instead of the global constraints. Describe alternatives you've considered I use a macro to make the resolve constraints and source file constraints match today, but this means constraints must be updated and match in multiple spots instead of just having

pants.toml

as the single source of truth. pantsbuild/pants

#22848 Corepack not installed with NodeJS 25 by default Issue created by sureshjoshi nodejs/nodejs.org#7555 This doesn't affect us yet, since we'll be on LTS generally, but if someone setups NodeJS 25, it could cause this to fall over (but, it might use the Pants corepack instead - I honestly have no idea). This will become a bigger issue when we hit NodeJS 26 LTS though. Need to install via userland, if we want to keep using this mechanism: https://nodejs.org/docs/v24.11.0/api/corepack.html#corepack https://github.com/nodejs/corepack Part of the convenience of corepack is not just installing the default package managers, but also being able to pick up and run the package manager in the package.json file. I think we'll now need to maintain a separate corepack subsystem to keep functionality. pantsbuild/pants

#18909 Blog about `pants test` and `pants package` Issue created by cczona Doesn't need to be long. Essentially a narrative elaboration on https://www.pantsbuild.org/docs/python-test-goal#depending-on-packages. pantsbuild/pants

#18887 Pitch Pants to more podcasts Issue created by cczona Note: a good combination of guests to pitch is either two core team members from different organizations, or one core team member plus one user from the general public. Either pairing brings a nice balance of perspectives and stories. Podcast guesting is always a fun and easy way to promote Pants, and does not require knowledge of the source code itself. Typically there is virtually no preparation required other than the pitch itself and a couple emails back and forth to schedule the interview time. Questions tend to be friendly and curious, from software engineering peers rather than hard-hitting journalists. Podcasters are interested in your unique perspective and experiences rather than probing whether you have exhausive knowledge of Pants. It's common for the interview to take an hour or less, with no other work on the interviewee's part. Many podcasts also offer the option to have something deleted from the recording upon request (confirm when scheduling). So if you stumble on your words, or need time to think about an answer, typically no one but you and the interviewers know. Some podcasts that potentially would be interested in Pants and related topics such as build engineering, devops, MLops, code quality, developer productivity, software quality, scaling, etc are: • Changelog https://changelog.com/podcast • Developer Tea Podcast "Top-ranked podcast for developers made to fit in your tea break. 12m+ downloads and counting by @jcutrell" https://mobile.twitter.com/DeveloperTea https://developertea.com/ http://ratethispodcast.com/devtea • Devtools.FM "A podcast about developer tools and the people who make them. Hosted by @hipstersmoothie and @zephraph. Interested in being a guest? Shoot us a DM!" https://mobile.twitter.com/DevtoolsFM • Django Chat Podcast "A weekly podcast on the Django Web Framework by Will Vincent and @carltongibson" https://mobile.twitter.com/ChatDjango • FOSS and Crafts "A podcast about free software, free culture, and making things together" https://mobile.twitter.com/fossandcrafts • Go Time (Changelog) https://changelog.com/gotime • Maintainable Software Podcast "We speak with seasoned practitioners who have worked past the problems related to technical debt and legacy code. Hosted by @planetargon CEO @robbyrussell" https://mobile.twitter.com/_maintainable https://maintainable.fm/episodes • Open Source Stories "Open source is collaboration, communication, community, and more. Open Source Stories collects these narratives from across the ecosystem." https://mobile.twitter.com/StoriesOfOSS • Python Bytes "A Python podcast covering recent developer headlines. Hosted by @mkennedy and @brianokken." pythonbytes https://pythonbytes.fm/episodes/all https://pythonbytes.fm/ • Rustacean Station "A community project for creating podcast content for the Rust programming language. Get in touch at hello@rustacean-station.org" https://mobile.twitter.com/rustaceanfm • Serverless Chats Podcast "A podcast that explores all things #serverless! Join @jeremy_daly & @beccaodelay as they chat with a special guest each week. New episodes return Feb. 7th!" https://mobile.twitter.com/ServerlessChats https://www.serverlesschats.com/episodes/ • The Confident Commit "Covering topics ranging from pipeline security to engineering team efficiency, The Confident Commit is for anyone looking to join the conversation on how to deliver software better and faster." https://open.spotify.com/show/32DhviAaIyB3U4iKEQ2k8B?mkt_tok=NDg1LVpNSC02MjYAAAGDGHvpFSnLccvGVLqusrJPoYvTOC0OA2ACNAPRpWIIgsRCpbmts6lJk5g76I21K_fakSeZWrFCIGZL9HCsm_f411ROCtPGJSXntFNGwSrYl9aVYsT5UNOcwg • The POPCAST with DanPOP "Connecting YOU with amazing people" https://mobile.twitter.com/PopcastPop http://bit.ly/35MXfte http://bit.ly/3xgmmCj Please add to this list! And if you are a fan of a podcast mentioned in this issue and think Pants folks would be good guests on it, please do let us and the podcast hosts know. Thank you! pantsbuild/pants

#22856 Pants ignoring `[python-repos]` when resolving lockfile Issue created by aebrahim Describe the bug Pants is only using the pypi registry in

indexes

to grab pip, setuptools and wheel, but not for other dependencies Pants version Which version of Pants are you using? 2.29 OS Only tested on Linux Additional info I am pretty sure I have set up the

toml

file correctly because pants is actually using it for these deps, which leads me to think the bug is in pants. pantsbuild/pants

#21346 Consider using executable_search_path in go backend Issue created by henri14 The Problem Whilst working on #21292 I noticed that the

go

backend uses separate options for search paths. These are

_go_search_paths

and

_cgo_tool_search_paths

. I needed an additional search path for the

extra-tools

option but ended up implicitly using the

_go_search_paths

. A number of other backends seem to use

executable_search_path

option. These are Docker, NodeJS, Pex and Shell. The Proposal Enhance the

go

backend to use

executable_search_path

for the go binaries, cgo tools and extra tools. This would be done by using the ExecutableSearchPathsOptionMixin. This would improve consistency in the options for the various backends. It does however impact existing configs that would need to be migrated. pantsbuild/pants

#22865 How do I specify a bundled file as a command line argument? New discussion created by aebrahim This is my use case, I am embedding a configuration file in my pex binary, and I would like to also pass that file in as a command line argument. For example: pex_binary( name="mybinary", script="mybinary", dependencies=[ "//configuration:my_configuration_file", ], include_tools=True, args=[ "--configuration_file", some_path_resolver("//configuration:my_configuration_file") ], ) What's the best way to do this? pantsbuild/pants

#18179 Individual versioning using semver/commitizen Issue created by IsmaelMartinez Is your feature request related to a problem? Please describe. When packaging multiple libraries, I don't find a way to increase their version number (patch, minor, major) automatically. Currently it requires to remember to edit the

pyproject.toml

file Describe the solution you'd like It would be ideal if the package command can automatically increase the version number depending on the commits by using commitizen or others. Describe alternatives you've considered Adding a plugin (probably better than a macro) might be able to archive this, but haven't had the time to explore that option. The idea is that it will run just before the package command and increase the version number of any libraries that has changed. Appreciate if you can provide more info in other ways and/or examples to archive this. Additional context We use poetry for our libraries, and have a mono repo that generates multiple libraries (for external systems to consume). An example. If I got 3 pyproject.toml that then I publish as libraries, called A,B and C. Assuming dependencies goes like this C -> B -> A. Meaning, B depends on A and C depends on B. • If A changes, I would like the version number for A, B and C to increase. • If B changes, I would like the version of B and C to change. • If C changes, Then I would like only the version in C to change. Does this make sense? A bonus extra would be to detect what number to increase depending on the commit (using git commitizen or similar) but I can live without that Our libraries have a poetry file like this:

[tool.poetry]
name = "library_1"
version = "2.0.0"
description = "my internal library"
authors = ["<mailto:blabla@blablabla.com|blabla@blablabla.com>"]
readme = "README.md"
repository = "<https://ohhh-this-url-is-amazing/but-is-not-real>"

[tool.poetry.dependencies]

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

Got a wee publish macro that looks like this:

# flake8: noqa: F821
def poetry_distribution(name, **kwargs):
    resources(name="package_data", sources=["pyproject.toml", "README.md"])

    python_distribution(
        name="dist",
        dependencies=[":package_data", f"src/python/{name}/src", "//:root"],
        provides=python_artifact(name=name),
        generate_setup=False,
    )

Then in the folder for each library I have this in the BUILD file

poetry_distribution(
    name="name-of-my-library",
)

The project structure is like this:

├── BUILD
├── dependencies.lock
├── dist
│   ├── library-1-2.0.0-py2.py3-none-any.whl
│   ├── library-1-2.0.0.tar.gz
│   ├── library-2-5.0.0-py2.py3-none-any.whl
│   ├── library-2-5.0.0.tar.gz
│   ├── library-3-3.0.0-py2.py3-none-any.whl
│   ├── library-3-3.0.0.tar.gz
│   ├── library-4-2.0.0-py2.py3-none-any.whl
│   └── library-4-2.0.0.tar.gz
├── pants
├── pants.toml
├── pants_plugins
│   ├── BUILD
│   └── macros.py <- This is where I have put the macro
├── pyproject.toml
├── setup.cfg
└── src
    └── python
        ├── library-1
        │   ├── BUILD
        │   ├── README.md
        │   ├── pyproject.toml
        │   ├── src
        │   │   ├── BUILD
        │   │   └── library-1.py
        │   └── test
        │       ├── BUILD
        │       └── test_library-1.py
        ├── library-2
        │   ├── BUILD
        │   ├── README.md
        │   ├── pyproject.toml
        │   └── src
        │       ├── BUILD
        │       ├── library-2.py
        │       ├── test_something_else_library-2.py
        │       └── test_library-2.py
        ├── library-3
        │   ├── BUILD
        │   ├── README.md
        │   ├── pyproject.toml
        │   └── src
        │       ├── BUILD
        │       ├── __init__.py
        │       ├── library-3.py
        │       └── test_library-3.py
        └── ppl_library-4
            ├── BUILD
            ├── README.md
            ├── pyproject.toml
            └── src
                ├── BUILD
                ├── ppl_library-4.py
                └── test_library-4.py

The only root source config I got in the pants.toml is

[source]
root_patterns = ['/src/python/*/src', '/']

And added also this like to activate the macros

build_file_prelude_globs = ["pants_plugins/macros.py"]

Thanks in advance!! From this slack message pantsbuild/pants

#18555 python_requirements Environment Markers Support Issue created by nikwotton Describe the bug Generating a lockfile using the same dependency listed twice with different environment markers fails. Pants version 2.15.0 OS MacOS and Linux in Docker Additional info I have an example repository setup for simplifying problems with pants. The exact scenario described above is demonstrated on this branch: https://github.com/nikwotton/Broken-Pants-Demo/tree/broken-lockfiles The same behavior is observed whether using

python_requirements

and requirements.txt, or using

python_requirement

blocks. pantsbuild/pants

#19549 Remove deprecated VS Code Python extension settings from docs Issue created by luabud Hi there! I'm a PM for Python in Visual Studio Code and I noticed there're references in the Pants docs to 3 settings that we have recently marked as deprecated in the Python extension. Specifically, all the

python.linting

and

python.formatting

settings have been deprecated as in the latest Python extension pre-release version, as we're migrating our tooling support to extensions (see here for more details). I figured I'd open this issue to suggest to remove them from the docs 😊 Thanks! pantsbuild/pants