How would I go about setting up my own definition of

publish

for a pex binary?

Curious if global git config settings are used during builds? Working with a go project that has a dependency to a private github repo. Following these go docs for git+https but still seeing an authentication error when packaging with pants.

Q. When I run

./pants package

with a

python_distribution("dist")

target in

src/ai/backend/common/BUILD

which depends on a

python_sources("lib")

target in the same file which depends on a

python_sources("stubs")

target in

stubs/trafaret/BUILD

, it says "No python_distribution target found to own stubs/trafaret/__init__.pyi:stubs". Shouldn't it be included in the original

src/ai/backend/common:dist

target transitively? I don't want to make a separate package for the type stubs but just embed it inside the

src/ai/backend/common:dist

package. How do I avoid the error without changing the directory structure?

Question regarding moving from

requirement_constraints = "constraints.lock"

to enabling resolves/pex lockfiles in 🧵

I'm running into an error when using the

package

goal on a project that has CPython>=3.6.* as an interpreter constraint (pants 2.11). Has anyone else experienced this issue? (Note: [setuptools.lockfile] is set to

"<none>"

)

File "/Users/KHowa8/.pyenv/versions/3.7.13/lib/python3.7/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'

I have hit what I think might be a pants bug, but maybe I am doing something wrong. I have a small refactor branch, which just breaks a few files up and when I run this I get a spurious error:

./pants lint --changed-since=master
...
src/util/celery.py:25:0: E0401: Unable to import 'raven.contrib.celery' (import-error)

But when running directly it works:

./pants lint src/util/celery.py  
...
✓ black succeeded.
✓ isort succeeded.
✓ pylint succeeded.

Curious if we can get pants execution to respect

~

? Seeing this error on some go builds:

exit status 128:\n\terror: could not expand include path '~/.gitcinclude'\n\tfatal: bad config line 44 in file /usr/local/git/etc/gitconfig

semi related to this thread: https://pantsbuild.slack.com/archives/C046T6T9U/p1652934048576209

Is there a way to get the path to an installed binary that Pants manages as a tool? I'm curious if there's a shortcut I could take to getting

buf

to perform a breaking-changes check on our protobufs short of diving into Pants code to implement it, maybe via

experimental_shell_command

?

Is there a way to tell pants to ignore inferred python string imports on a case-by-case basis?

Since the length of a goal name came up the other day, is there background on why it's

generate-lockfiles

instead of something like

lock

?

Hello, a coworker of mine is running into some trouble when using Pants. In our

pants.toml

file, we have the following:

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

However, when he runs Pants commands, he sees the following line:

Bootstrapping Pants using /usr/local/bin/python3.7

This is problematic because we use Python 3.9 features, which is causing his runtime to fail. What is the reason that Python 3.7 is being used here?

We run linters and formatters via pants as part of our git pre-commit hooks and I have found a behavior I don't understand. When the only file changes is a BUILD file, pants will try a bunch of other files (maybe ones owned by that file?). Is that expected?

Is there a way to have Pants only lint Docker images, but not build? That is, if I run

./pants package ::

, is there a way to not have it try to build the images?

If I wanted to extend the options for the

[pex]

section, is that as simple as subclassing

pants.backend.python.util_rules.PexRuntimeEnvironment

?

In some places, I see `@rule`s taking in a

FieldSet

and in other places I see them taking in a

Request

. Is there a general consensus on which is preferred? Seems like those who pass in `FieldSet`s typically specify the

request_type

attribute while the other way around is to specify the

field_set_type

. Are they equivalent ways of doing things?

I only see examples for using

Process

(or a subclass of it). What could I reference for when I don't need this functionality (e.g. the library doing the work is a python library in the plugin environment and not a call out to the system)?

Is there a way to deal with cases where there are two third-party libraries being used, but both have the same name? In my project, I use both the

google-api-python-client

and

google-auth

libraries. In Python code, they're both referred to as

google

, for example:

from google import auth
from google import api_core

I noticed that I can't specify two separate

module_mappings

where the values are the same, otherwise the build system gets confused...

I'm having some odd rule behavior that I'd appreciate some eyes on when folks have a minute

We're using the python_awslambda target and experiencing cold starts of 500ms out of the gate... Is this usual? Or is there something we need to configure?

package size was awesome at <500kb vs 10MB but cold starty is terrible

Hello again, is there a Pants best practice for releasing artifacts from a monorepo? Specifically, are all my subprojects that produce an artifact (e.g. a python wheel) going to have the same version? If this is the case, how do I parametrise/inject the version value into the

python_distribution

targets? This is kindof related to my previous question about getting the output of git describe

Hi everyone, I’m struggling to make my

flask

pex

works with

gunicorn

, having tried with

entry_points

and

PEX_SCRIPT

./pants run xxx

works perfectly fine Once I try to have it running with

gunicorn

(from local or from a docker image, which is the ultimate goal), I can’t seem to find the right syntax for the module/app

COPY packages.hello_world/main.pex packages/hello_world/main.pex

CMD ./packages/hello_world/main.pex packages.hello_world.main:app

Will give me the following error:

/pants run packages/hello_world    
/Users/quentin/.cache/pants/setup/bootstrap-Darwin-arm64/2.11.0_py39/bin/pants
15:34:54.78 [INFO] Canceled: Building docker image hello_world:latest
15:34:56.01 [INFO] Completed: Building docker image hello_world:latest
[2022-05-20 19:34:57 +0000] [8] [INFO] Starting gunicorn 20.1.0
[2022-05-20 19:34:57 +0000] [8] [INFO] Listening at: <http://127.0.0.1:8000> (8)
[2022-05-20 19:34:57 +0000] [8] [INFO] Using worker: sync
[2022-05-20 19:34:57 +0000] [11] [INFO] Booting worker with pid: 11
[2022-05-20 19:34:57 +0000] [11] [ERROR] Exception in worker process
Traceback (most recent call last):
  File "/root/.pex/venvs/s/4323ba33/venv/lib/python3.9/site-packages/gunicorn/arbiter.py", line 589, in spawn_worker
    worker.init_process()
  File "/root/.pex/venvs/s/4323ba33/venv/lib/python3.9/site-packages/gunicorn/workers/base.py", line 134, in init_process
    self.load_wsgi()
  File "/root/.pex/venvs/s/4323ba33/venv/lib/python3.9/site-packages/gunicorn/workers/base.py", line 146, in load_wsgi
    self.wsgi = self.app.wsgi()
  File "/root/.pex/venvs/s/4323ba33/venv/lib/python3.9/site-packages/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/root/.pex/venvs/s/4323ba33/venv/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 58, in load
    return self.load_wsgiapp()
  File "/root/.pex/venvs/s/4323ba33/venv/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/root/.pex/venvs/s/4323ba33/venv/lib/python3.9/site-packages/gunicorn/util.py", line 359, in import_app
    mod = importlib.import_module(module)
  File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 984, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'packages.hello_world.main'
[2022-05-20 19:34:57 +0000] [11] [INFO] Worker exiting (pid: 11)
[2022-05-20 19:34:57 +0000] [8] [INFO] Shutting down: Master
[2022-05-20 19:34:57 +0000] [8] [INFO] Reason: Worker failed to boot.

I’ve been trying multiple syntax, and I either get:

Failed to find attribute 'app' in 'packages.hello_world'.

or

ModuleNotFoundError: No module named 'packages.hello_world.main'

which tells me that • the package

packages.hello_world

exists • the package `packages.hellow_world.main`doesn’t exist • there is no

app

attribute in the package • there is no

main

attribute in the package folder structure is:

/packages/hello_word
|- Build
|- Dockerfile
|- main.py

You can find a repo to reproduce the issue here: https://github.com/qventura/pants-flask/tree/main/packages/hello_world Thanks in advance, if anyone can help me finding the right way to start my app, I’ll be grateful!

When using Pex for lockfile generation, will

./pants generate-lockfiles

always regenerate from scratch? If so, is there an equivalent of

poetry lock --no-update

(see here) so that transitive dependencies stay on the same versions as before, if they have no need to change?

I'm getting resolves working with our codebase and running into an issue I can't understand. Linting the entire repo works locally (linux), but fails in CI with an error parsing the

markdown

package. Details in 🧵

I'm seeing the scheduler restart a lot more often than I would expect, and this is on a small repo. There is nothing in

.pants.d/pants.log

to tell me why.

When writing a plugin, what's the best way to say "get me all Python targets in the codebase that end with `"_some_suffix.py"`"? I saw that

AllTargets

and

AllTargetsRequest

exist, and also saw that in the Python backend, there was

PythonSourceTarget

. Was wondering if there was a way to make a request to get all Python targets with some suffix

Some improvements coming to command-line arguments in Pants 2.13 🥳 1. "target-less" goals like

update-build-files

,

tailor

, and

count-loc

now behave the same as "target-aware" goals like

list

.

./pants count-loc ::

runs on all files, and

./pants --changed-since=HEAD update-build-files

only will run on changed BUILD files 2.

./pants test dir

now does what you'd intuitively expect. Before, it would run on the target that left off the

name=

field 🤦 now, you can set an option so that directories == all targets & files in the directory 3.

filter

options work from anywhere. Before:

./pants filter --target-type=python_test :: | xargs ./pants test

. After:

./pants --filter-target-type=python_test test ::

May be a dumb question, but in upgrading to pants 2.11 is there any way to get

python_library

(which is deprecated) and

python_sources

to co-exist? I currently have a setup that would allow me to use different version of pants in parallel while I upgrade small pieces at at time (rather than have 200+ BUILD files changed at one time and risk breaking everything in the process). Even if I told pants to ignore unknown types, that would be OK

I'm having trouble following the source. Where exactly does something like

{<http://build_args.MY|build_args.MY>_ARG}

get translated into its

KEY=VALUE

pair for docker image tagging?

I am upgrading from pants 2.9.0 to 2.11.0 and

pants export ::

is taking significantly longer. From 20 sec to 150 sec. Is that expected?