#17551 deprecation warning on Python 3.10 Issue created by tdyas On latest

main

with Python 3.10.7:

11:07:09.96 [WARN] /REDACTED/pants/src/python/pants/engine/streaming_workunit_handler.py:292: DeprecationWarning: isSet() is deprecated, use is_set() instead
  while not self.stop_request.isSet():

pantsbuild/pants

#17553 Large `node_modules` directories exhaust pantsd's memory limit New issue created by chrisjrn To reproduce: • clone the repo at https://github.com/danxmoran/pants-yarn-install-repro (mentioned in #16825) • Add the

pants_from_sources

script • Run

ENABLE_PANTSD=True ./pants_from_sources run :run-yarn-install

• Run

ENABLE_PANTSD=True ./pants_from_sources run :run-yarn-install

a second time Definitely after the second run, no

pantsd

processes will be running. pantsbuild/pants

#17554 `poetry_requirements` includes `[tool.poetry.dev-dependencies]` dependencies New issue created by ioangatop Description When producing distributions using the command

./pants package ::

, where each

BUILD

of a library installs requirements with

poetry_requirements

, installs both

[tool.poetry.dependencies]

and

[tool.poetry.dev-dependencies]

, which should not happen, at least by default. Pants version 2.14 OS MacOS Additional info Here some sample project files;

# BUILD file

poetry_requirements(name="lib-reqs")

python_sources(
    name="lib",
    sources=["libs/lib/**/*.py"],
    dependencies=[":lib-reqs"],
)

python_distribution(
    name="lib-dist",
    dependencies=[":lib"],
    provides=python_artifact(name="lib"),
    sdist=False,
)

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

[tool.poetry]
name = "lib"
version = "0.0.1"
description = "lib purpose."

[tool.poetry.dependencies]
python = ">=3.8"
numpy = "^1"

[tool.poetry.dev-dependencies]
pytest = "^7.1.2"
black = "^22.3.0"
flake8 = "^4.0.1"

pantsbuild/pants

#17557 pyright: support locking with version and lockfile Issue created by smelc At the moment

pants

doesn't support specifying `pyright`'s version. I tried specifying it as follows:

backend_packages = [
  "pants.backend.experimental.python.typecheck.pyright",
  ...
]

[pyright]
version = "pyright==1.1.258"
lockfile = "pants_dir/3rdparty/pyright_lockfile.lock"

However this doesn't work:

> PANTS_SHA=11b4fd412631c6315b474e49fe482dec1767cf29 ./pants check libs/wsi::
...
15:23:58.49 [ERROR] Invalid option 'lockfile' under [pyright] in /home/churlin/dev/kaiko-eng/pants.toml
15:23:58.49 [ERROR] Invalid option 'version' under [pyright] in /home/churlin/dev/kaiko-eng/pants.toml
15:23:58.49 [ERROR] Invalid config entries detected. See log for details on which entries to update or remove.
(Specify --no-verify-config to disable this check.)

This is a bummer because it makes it impossible to pin

pyright

version, reducing reproducibility of our CI setup 😞 Would it be possible to support

pyright

pinning? pantsbuild/pants

#16803 Ability to `run` (or `package`?) an `experimental_shell_command` Issue created by danxmoran Is your feature request related to a problem? Please describe. Currently (as far as I can tell) the only way to test that an

experimental_shell_command

works properly is to wire it up to a downstream target (the docs mention

docker_image

) and have the build process for that target inspect the shell outputs. There's no way to run the command in isolation to manually check its outputs in isolation, which is a drag when you're prototyping / debugging. Describe the solution you'd like The ability to

./pants run

an

experimental_shell_command

target and have the outputs appear under

dist/

. If it's weird for a

run

command to produce

dist/

output, I could also see an argument for

package

on these targets. Describe alternatives you've considered The work-around is to add a downstream target and use that target to inspect the shell command's outputs. Doable, but an unfortunate hoop to jump through. Additional context The related

experimental_run_shell_command

is

run

-able, but you can't have any other targets depend on its output. pantsbuild/pants

#17559 Please add Whisper to the public list of Pants Users Issue created by asgoel Company name Whisper Company website https://whisper.ai Company logo Copy of whisper_logo_RGB_Blue pantsbuild/pants

#1981 Add an option like Python's `-P`, which doesn't prepend certain paths to sys.path New issue created by thejcannon See https://docs.python.org/3/using/cmdline.html#cmdoption-P It'd be great if PEX has a similar option. pantsbuild/pex

#17562 Fetching with coursier indefinitely New issue created by sureshjoshi On making some changes to the

javascript

backend on 3-4 python files, I tried to format but got suck here:

⏺ oss/pants-pyright % ./pants --changed-since=origin/main fmt                     ⎇ 17557-npx-dep-version*
⠠ 107.83s Fetching with coursier: org.scala-lang:scala-reflect:2.13.7
⠤ 107.73s Fetching with coursier: org.jline:jline:3.20.0
⠤ 107.73s Fetching with coursier: org.scalameta:scalafmt-interfaces:3.2.1
⠤ 107.73s Fetching with coursier: org.scala-lang.modules:scala-parallel-collections_2.13:1.0.4
⠤ 107.73s Fetching with coursier: org.scala-lang:scala-compiler:2.13.7

Note:

--changed-since=origin/main

is my fork, so it's up in sync with my branch, except for those 3-4 files. On running this yesterday, I cancelled after about 3600 seconds, and today after 2400 seconds. As far as I know, none of this should even be running in the first place (at least, I would hope). This is not a new problem, I've had it happen several times in the past few months. Environment

'c.          
                 ,xNMM.          ----------------- 
               .OMMMMo           OS: macOS 13.0.1 22A400 x86_64 
               OMMM0,            Host: Macmini8,1 
     .;loddo:' loolloddol;.      Kernel: 22.1.0 
   cKMMMMMMMMMMNWMMMMMMMMMM0:    Uptime: 5 days, 11 hours, 2 mins 
 .KMMMMMMMMMMMMMMMMMMMMMMMWd.    Packages: 172 (brew) 
 XMMMMMMMMMMMMMMMMMMMMMMMX.      Shell: zsh 5.8.1 
;MMMMMMMMMMMMMMMMMMMMMMMM:       Resolution: 2560x1080 
:MMMMMMMMMMMMMMMMMMMMMMMM:       DE: Aqua 
.MMMMMMMMMMMMMMMMMMMMMMMMX.      WM: Quartz Compositor 
 kMMMMMMMMMMMMMMMMMMMMMMMMWd.    WM Theme: Blue (Dark) 
 .XMMMMMMMMMMMMMMMMMMMMMMMMMMk   Terminal: Apple_Terminal 
  .XMMMMMMMMMMMMMMMMMMMMMMMMK.   Terminal Font: SFMono-Regular 
    kMMMMMMMMMMMMMMMMMMMMMMd     CPU: Intel i5-8500B (6) @ 3.00GHz 
     ;KMMMMMMMWXXWMMMMMMMk.      GPU: Intel UHD Graphics 630 
       .cooc,.    .,coo:.        Memory: 17866MiB / 32768MiB

pantsbuild/pants

#1982 Should `pex ... -e module` be prepending CWD? Issue created by thejcannon According to https://docs.python.org/3/library/sys.html#sys.path

python -m module

prepends CWD to

sys.path

.

$ cat code/foo.py 
import sys
import os

def main():
    print(os.getcwd())
    print(sys.path)


if __name__ == "__main__":
    main()

$ python -m code.foo
/home/josh/work/pants
['/home/josh/work/pants', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/josh/.local/lib/python3.8/site-packages', '/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages']

* * * PEX help says:

-m MODULE[:SYMBOL], -e MODULE[:SYMBOL], --entry-point MODULE[:SYMBOL]
                        Set the entry point to module or module:symbol. If just specifying module, pex behaves like python -m, e.g. python -m SimpleHTTPServer. If specifying
                        module:symbol, pex assume symbol is a n0-arg callable and imports that symbol and invokes it as if via `sys.exit(symbol())`. (default: None)

So presumably using

pex -D code -e foo

would act like

python -m code.foo

, however:

$ pex -D=code -e foo
/home/josh/work/pants
['/tmp/tmpnu421wmb', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/tmp/tmpnu421wmb/.bootstrap']

even if I twiddle with `PEX_INHERIT_PATH:

$ PEX_INHERIT_PATH=fallback pex -D=code -e foo
/home/josh/work/pants
['/tmp/tmpfauv3vos', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages', '/tmp/tmpfauv3vos/.bootstrap']

$ PEX_INHERIT_PATH=prefer pex -D=code -e foo
/home/josh/work/pants
['/tmp/tmpyj_l3y5m', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages', '/tmp/tmpyj_l3y5m/.bootstrap']

* * * Furthermore using a function spec:

$ pex -D=code -e foo:main
/home/josh/work/pants
['/tmp/tmp0kfzbnkw', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/tmp/tmp0kfzbnkw/.bootstrap']

(It's a big ambiguous if this should prepend CWD as per

python -m

or

""

as per

python -c

as it all depends on how the

entry_point

runner is invoked.) pantsbuild/pex

#17039 Python dependency inference: add/emit debugging information Issue created by lilatomic Is your feature request related to a problem? Please describe. There currently isn't any information emitted about what dependencies were inferred. If dependency inference fails, developers don't have much to pinpoint the error. For concrete usecases: • I ran into an issue where dependent files weren't pulled into a test PEX. This was due to some shenanigans I had with pants source roots, where the imports were resolved from the repository root, not the closest parent source root. • I ran into an issue where guarded imports weren't pulled into a test PEX. I had the incorrect module path, but the PEX built fine because they were weak imports Describe the solution you'd like A good first pass would be having the ability to output, • for every file, the imports found and whether they were resolved. • the map of 3rd party dependencies to modules • the map of 1st party targets to modules This would help developers confirm that the imports were found and understand if the targets of the import were found or ignored. For the example, with the second usecase, the imports found I would expect something like the following to let me know that it was deliberate and acceptable that there wasn't an error not resolving the imports:

[
  {
    "path": "//folder/file.py",
    "imports": [
      {
        "import": "a.b.c",
        "weak": true,
        "resolved": false
      }
    ]
  }
]

Describe alternatives you've considered The current output is just checkpointing. With

-ltrace

, these are what is printed (many messages elided):

11:31:51.66 [DEBUG] Completed: Find all targets in the project
11:31:51.66 [DEBUG] Completed: Find all Python targets in project
11:31:51.66 [DEBUG] Completed: Creating map of third party targets to Python modules
11:31:51.67 [DEBUG] Completed: Creating map of first party Python targets to Python modules
11:31:51.67 [TRACE] Completed: Inferring Python dependencies by analyzing source
11:31:51.67 [TRACE] Completed: Inferring Python dependencies by analyzing source

Additional context rel: #13283 ; this requests information on dependency inference, that requests graphing the normal dependencies. Discussion in that mentions graphing at different scopes, this mentions a scope below what could ordinarily be graphed by that. pantsbuild/pants

#17564 New option to ignore untracked files New issue created by kaos Is your feature request related to a problem? Please describe. When running

./pants lint

etc it some times fails due to bad files in the source tree but that is not part of the checked out git work tree. This may be files that are wip, temporary labs etc (the tree is dirty in other words), but for various reasons would prefer not to have to remove them for the purpose of running lint etc on my tracked sources. Describe the solution you'd like An option to automatically add to the list of ignores any files not currently tracked by git. Describe alternatives you've considered Cleaning out the source tree before running lint, or carefully providing specs that avoids them. Additional context Frequent enough issue to be a bother worth fixing, imho. Particularly difficult to work around while still preserving the files when hit by a pre-commit git hook. pantsbuild/pants

#17565 Protect dependencies of python packages distributed on internal vs external indexes Issue created by cognifloyd Is your feature request related to a problem? Please describe. Publishing artifacts should be immutable. But, some things should have access to supplemental resources, and others should not. If building a wheel for internal distribution, anything in an internal supplemental index is fair game. If building something to go on an external index, like pypi, then that should be restricted so it can only see the publicly accessible artifacts. It would be nice if pants guarded against mismatched dependencies earlier in the dev cycle. Describe the solution you'd like Per resolve find_links and indexes settings instead of (or in addition to) global `[python-repos].indexes`and

[python-repos].repos

(bonus points for renaming

repos

to

find_links

to make that settings purpose clearer and less confusing). So, we would have two new settings: •

[python].resolves_to_find_links

•

[python].resolves_to_indexes

This is also more consistent with the rest of the settings, making it more predictable for new users. To continue supporting the old, global settings, I would probably use that as the default for resolves that do not specify anything under

[python].resolves_to_*

. Describe alternatives you've considered We may be able to use the new dependency rules feature, and the visibility backend, to approximate this. It would probably require setting

__dependent_rules__

that prevent any public distributions from depending on a

python_requirement

that is only known to exist on the private index. But, that's would be hard to maintain, and hard to create initially. This approach would probably be reactive: any time publishing a wheel to pypi fails due to using internal dependencies, people would add another dependent rule to protect against a given bad dependency. This might become even more murky if the same package is available in both indexes, but you need to constrain the allowed/locked versions based on which index will be used to distribute some wheel (s). Additional context I don't need this feature yet. The proposed solution was discussed on slack: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1660577710953089?thread_ts=1660577710.953089&cid=C0D7TNJHL But having this feature would make using pants more appealing in more contexts. As I said in slack:

With things the way they are, I would insist that devs have to use separate repos for public vs private stuff - ie monorepo is not an option. But, if there's a way to handle that nicely, then I might have a reason to push people to use monorepos in more places. I have a series of repos that are divided between public/private. there are issues other than the repos config that prevent me from unifying them, but stepping toward mono(ish) repos is a very enticing prospect.

And if I do publish a lockfile, the internal index should never be visible.

as far as people outside the org know, no such index exists. 🙂

So, if anyone else could use this feature, please chime in so we can gauge community interest. pantsbuild/pants

#17571 docker_image source=None not working New issue created by tareshsethi Describe the bug I am trying to use the instructions field for docker_image. I have a docker_image target that looks like

docker_image(
    name="srcs",
    dependencies=['...'],
    registries=['...'],
    repository='...',
    instructions=['FROM ...',
    source=None,
    image_tags=['...'],
)

and I get the following error when i do a pants peek on srcs:

InvalidFieldException: The `docker_image` ... provides both a Dockerfile with the `source` field, and Dockerfile contents with the `instructions` field, which is not supported.
To fix, please either set `source=None` or `instructions=None

Setting source='' seems to solve it, but the docs say setting to None should work. And i would also assume the ideal behavior would be that setting

instructions

would automatically override the source arg? Thank Pants version 2.14.0 OS Only have tested on MacOS Monterey 12.0.1, Intel pantsbuild/pants

#17576 windows support? New issue created by liudonghua123 Is your feature request related to a problem? Please describe. No, it's just an os platform support. Describe the solution you'd like Support windows platform. Describe alternatives you've considered N.A. Additional context N.A. pantsbuild/pants

#17581 Pants should be able to tell if its launcher script is up-to-date New issue created by chrisjrn Watching the back-and-forth on #17563, we're running into an issue with the

VERSION

file again. We didn't change it in the first place because the path to the `VERSION` file is hardcoded into the launcher script. Moving the

VERSION

file has been assessed to have minimal impact, because it only affects users of

PANTS_FROM_SHA

, however, with future changes (such as adding new distribution formats), it would be useful to alert users to the launcher script changing, in case the breakage is more severe. pantsbuild/pants

#17585 `deploy_jar` attempts to build Java source files that do not exist in the package New issue created by chrisjrn Attempting to build a

deploy_jar

results in:

FileNotFoundError: [Errno 2] No such file or directory: '/Users/chrisjrn/src/pants/src/python/pants/jvm/jar_tool/src/java/org/pantsbuild/args4j'

Took a look through the unzipped pants wheel, and the relevant files are nowhere to be found. pantsbuild/pants

#17590 Add output_path field to python_distribution New issue created by mvashishtha I have build rules in a file for a pex and a wheel. when i build both with

./pants package ponder/::

, the pex goes into a folder within dist at

dist/ponder/ponder_bin.pex

. the wheel goes straight into the top level of

dist

at

dist/ponder-0.0.3-py3-none-any.whl

. is there any way to control the location of the output wheel? i want the wheel to go in

dist/ponder

too. here is the `ponder/BUILD`:

# resource(name="pyproject", source="pyproject.toml")

pex_binary(
    name="ponder_bin",
    entry_point="__main__.py",
)

python_distribution(
    name="ponder_wheel",
    dependencies=["//:something_at_root"],
    provides=python_artifact(
        name="ponder",
        version="0.0.3",
    ),
    sdist=False
)

python_sources()

slack context: https://pantsbuild.slack.com/archives/C046T6T9U/p1668755087112079 pantsbuild/pants

#17592 go: fix cgo bugs preventing kafka module from working with cgo Issue created by clsx524 Is your feature request related to a problem? Please describe. currently pants doesn't support .h files in the repo and compilation would result in errors

GoThirdPartyPkgError: The third-party package <http://github.com/confluentinc/confluent-kafka-go/kafka|github.com/confluentinc/confluent-kafka-go/kafka> includes `HFiles`, which Pants does not yet support. Please open a feature request at <https://github.com/pantsbuild/pants/issues/new/choose> so that we know to prioritize adding support. Please include this error message and the version of the third-party module.

for example, it would encounter this error when depending on this error. https://github.com/confluentinc/confluent-kafka-go/blob/master/kafka/glue_rdkafka.h Describe the solution you'd like support .h file Describe alternatives you've considered NA Additional context NA pantsbuild/pants

#17593 Include explicit transitive 3rdparty dependencies in packaged `python_distribution`s install requires New issue created by kaos Is your feature request related to a problem? Please describe. When using

overrides

for a

python_requirement

to add missing dependencies (in other words likely for a bad 3rd party dep) it would be sweet if I didn't have to do it again for all the

python_distribution

targets that depend on this 3rd party library. Describe the solution you'd like Include the explicitly added dependencies on 3rd party deps in the list of required dists in

setup.py

. Describe alternatives you've considered Manually duplicating the dependency on the

python_distribution

. Tedious and error prone. Additional context Take this dist for example: https://github.com/kaos/lockfile-diff/blob/f631695c838811acf5c7b8b00a02d2e4cc5db638/src/lockfile_diff/BUILD#L3-L10 Where I figured the

phx-class-registry

library requires

pkg_resources

from

setuptools

but it isn't listed, so sorted it with this override: https://github.com/kaos/lockfile-diff/blob/f631695c838811acf5c7b8b00a02d2e4cc5db638/3rdparty/BUILD#L6-L10 However, this version of my lockfile-diff is still broken, as I didn't also include

setuptools

as a dependency for my distribution. Foot-gun blast. pantsbuild/pants

#17597 deprecation warning for `python-dump-source-analysis` goal New issue created by tdyas Deprecation warning encountered after #17057:

19:51:58.21 [WARN] DEPRECATED: Setting `Goal.environment_behavior=EnvironmentBehavior.UNMIGRATED` for `Goal` `python-dump-source-analysis` is scheduled to be removed in version 2.17.0.dev0.

pantsbuild/pants

#17598 deprecation warning should display package that triggered the deprecation New issue created by tdyas Saw the following deprecation warning while developing on pants

main

branch:

20:01:54.23 [WARN] DEPRECATED: `pants.engine.environment.Environment` is scheduled to be removed in version 2.17.0.dev0.

Use `pants.engine.env_vars.EnvironmentVars`.
20:01:54.23 [WARN] DEPRECATED: `pants.engine.environment.EnvironmentRequest` is scheduled to be removed in version 2.17.0.dev0.

Use `pants.engine.env_vars.EnvironmentVarsRequest`.
20:01:54.25 [WARN] DEPRECATED: `pants.engine.environment.CompleteEnvironment` is scheduled to be removed in version 2.17.0.dev0.

Use `pants.engine.env_vars.CompleteEnvironmentVars`.

It is probably coming from the Toolchain plugin, but the deprecation warnings do not display the package that is triggering the deprecation warning. They should. pantsbuild/pants

#17604 Rule graph should warn or error for unused/unreachable rules New issue created by stuhood The

RuleGraph

does not currently check for unused-but-installed

@rules

(but it used to). Re-enabling these checks would help to catch some "silent" errors. pantsbuild/pants

#17605 Start building `*_macosx_12_0_*` wheels New issue created by danxmoran Is your feature request related to a problem? Please describe. We are simultaneously: 1. Upgrading to Pants 2.15.x 2. Experimenting with switching from Rosetta-on-M1 to native-M1 development for engineers with the hardware At least one user has started seeing the following error when they try running

./pants lint ::

on native M1:

Failed to resolve compatible artifacts from lock 3rdparty/lockfiles/resolves/pants-plugins.lockfile for 1 target:
1. /Users/david.cain/.asdf/installs/python/3.8.14/bin/python3.8:
    Failed to resolve all requirements for cp38-cp38-macosx_12_0_arm64 interpreter at /Users/david.cain/.asdf/installs/python/3.8.14/bin/python3.8 from 3rdparty/lockfiles/resolves/pants-plugins.lockfile:

Configured with:
    build: True
    use_wheel: True

Dependency on pantsbuild-pants not satisfied, 1 incompatible candidate found:
1.) pantsbuild-pants 2.15a1 (via: pantsbuild.pants<2.16,>=2.15.0a0) does not have any compatible artifacts:
    <https://files.pythonhosted.org/packages/e6/ab/726a3bfb6917ebd8afacd51218ae74b091e9f9dbc56d9563ae032156c9d8/pantsbuild.pants-2.15.0a1-cp39-cp39-manylinux2014_x86_64.whl>
    <https://files.pythonhosted.org/packages/26/31/73ddc6e67e8d860c812c8a72825f7c280eeef731208a327dfc3ddd3186a0/pantsbuild.pants-2.15.0a1-cp39-cp39-macosx_10_15_x86_64.whl>
    <https://files.pythonhosted.org/packages/88/d9/b5519dfc41180e1e77ba77617b5e010d347d62ff3f84ff7634bf2705adc4/pantsbuild.pants-2.15.0a1-cp39-cp39-macosx_10_16_x86_64.whl>
    <https://files.pythonhosted.org/packages/a9/01/02389079a9ec0f7d392af694f135a4e8c3e0b95decdcfba41c7fea4003e6/pantsbuild.pants-2.15.0a1-cp37-cp37m-macosx_10_15_x86_64.whl>
    <https://files.pythonhosted.org/packages/ac/d8/b2c76941ac8c26ddaac8374bfc718b69948aa8d60ae714763997a267dcb1/pantsbuild.pants-2.15.0a1-cp38-cp38-manylinux2014_x86_64.whl>
    <https://files.pythonhosted.org/packages/b5/61/4a9c2f947f22995abf303cc32611b46297fbe7555e9464707b7afa85f15a/pantsbuild.pants-2.15.0a1-cp38-cp38-macosx_10_15_x86_64.whl>
    <https://files.pythonhosted.org/packages/bf/0d/c3f8ca3a0c73242f71a1c9b6f1721a943bb53195b0659166a7f69e68ab26/pantsbuild.pants-2.15.0a1-cp39-cp39-macosx_11_0_arm64.whl>
    <https://files.pythonhosted.org/packages/f2/dd/3c9c256fa9bb8dac82465e12a852f35c83aeb9e18a2b90734f2c2976f72c/pantsbuild.pants-2.15.0a1-cp38-cp38-macosx_11_0_x86_64.whl>
    <https://files.pythonhosted.org/packages/fa/51/6675a59a5d627881b3fcf6b19b51bd01dc73d618cd6d08a89523900f52fd/pantsbuild.pants-2.15.0a1-cp37-cp37m-macosx_10_16_x86_64.whl>
    <https://files.pythonhosted.org/packages/fe/d9/35a394cd267a1911506cc4cbcb08cda15c38b68dacfcbee1ed62f7716e4e/pantsbuild.pants-2.15.0a1-cp37-cp37m-manylinux2014_x86_64.whl>

I thought it might be an issue with our lockfile, but looking on PyPI I don't see any

*_macosx_12_0_*

wheels. Describe the solution you'd like Add

*_macosx_12_0_*

wheels to the artifacts built during releases. Describe alternatives you've considered I'm completely ignorant in this area so I'm not sure if it's possible to "trick" Pants into using the

*_macosx_11_0_*

wheels. If so we would be willing to try that 😄 Additional context The user is running macOS 12.6 Monterey on their arm64 machine (I originally thought they'd upgraded to v13 Ventura, but I was wrong). I'm also running 12.6 Monterey on my x86_64 machine and haven't hit this problem 🤔 pantsbuild/pants

#12523 Subsystems not labeled with their backend on the docsite Issue created by stuhood Labeling subsystems with their backends would make it clearer which backends needed to be enabled in order to activate certain features. It would also make it safe(r) to render experimental backends on the docsite. Relates to #8992. pantsbuild/pants

#1986 Release 2.1.115 New issue created by jsirois On the docket: ☑︎ Allow for sorting the requirements when exporting requirements.txt #1988 ☑︎ Exported requirements.txt using different (abbreviated) version from lock.json #1989 pantsbuild/pex

#1988 Allow for sorting the requirements when exporting `requirements.txt` New issue created by thejcannon This allows for much easier diffing (migrating from

pip-tools

) and grokking (trying to scroll and find) pantsbuild/pex

#17613 Allow the publish goal for Docker images to push images in parallel New issue created by Gaasmann I have a project creating several Docker images to be used by AWS Lambdas and we push those images to ECR. There is some lag each time we start pushing an image to ECR. Pants is currently pushing each image sequentially. Consequently, the

publish

goal takes much more time than it could take if it were pushing images in parallel. Describe the solution you'd like I'd like Pants to be able to push Docker images (via the publish goal) in parallel rather than sequentially. Describe alternatives you've considered No alternative (besides suffering) comes to mind. :-) pantsbuild/pants

#17614 Expose field default values in a BUILD file New issue created by thejcannon Is your feature request related to a problem? Please describe. When I want to add a source to a

python_sources

field, I have to repeat the default globs (which includes remembering to omit tests and include

.pyi

files). This is painful and not upgrade-friendly. Additionally, people want to do

python_sources(sources=["**/*.py"])

however, that isn't quite right (again, tests and pyis, and conftests). Describe the solution you'd like A way to refer to the defaults inside my BUILD file so I can mangle it. Strawman:

# Using `python_sources.sources.default`
python_sources(
    sources = python_sources.sources.default + ["TotallyAPythonFile"]
)
# or
python_sources(
    sources = [
        "**/" + default for default in
        python_sources.sources.default   
    ]
)

Describe alternatives you've considered Hardcording 🤮 Additional context 🎩 pantsbuild/pants

#1989 Exported `requirements.txt` using different (abbreviated) version from `lock.json` New issue created by thejcannon Lock with PEX:

$ pex3 lock create --indent 2 absl-py~=0.10.0 | tee lock.json | grep 0.10.0
              "url": "<https://files.pythonhosted.org/packages/b9/07/f69dd3367368ad69f174bfe426a973651412ec11d48ec05c000f19fe0561/absl_py-0.10.0-py3-none-any.whl>"
          "version": "0.10.0"
    "absl-py~=0.10.0"

Then export the lockfile:

$ pex3 lock export lock.json 
absl-py==0.10 \
  --hash=sha256:ea07d7d437798bffc14f39fccec3909d251a1e76e233205ded72b71c267e0178
six==1.16 \
  --hash=sha256:8abb2f1d86890a2dfb989f9a77cfcfd3e47c2a354b01111771326f8aa26e0254

and note

absl-py

and

six

has been truncated from

0.10.0

to

0.10

, and

1.16.0

to

1.16

.

pip

, of course doesn't care. But migrating from

pip-tools

(specifically

pip-compile

) created

requirements.txt

to `pex`'s exported one, I get a noisy diff due to the change. pantsbuild/pex

#12943 go: assembly may require generation of go_asm.h file New issue created by tdyas Assembling Go assembly

.s

files may require generation of a

go_asm.h

with metadata from the

.go

files in the same package. See https://golang.org/doc/asm#data-offsets:

If a package has any .s files, then go build will direct the compiler to emit a special header called go_asm.h, which the .s files can then #include. The file contains symbolic #define constants for the offsets of Go struct fields, the sizes of Go struct types, and most Go const declarations defined in the current package. Go assembly should avoid making assumptions about the layout of Go types and instead use these constants. This improves the readability of assembly code, and keeps it robust to changes in data layout either in the Go type definitions or in the layout rules used by the Go compiler.

pantsbuild/pants