or maybe the better way to do this is have everything talk to the “remote instance” or host???

oh - I didn't mean one to run Pants via Docker. I was looking for something to take a built artifact and create and push an image with it. So

./pants docker-push something

would build

something

, then build an image containing it, and then push it somewhere.

ah sorry @plain-carpet-73994 though you were respondinng to my thread… didnt realized i was still in the geneeral channel. long day

General FYI for folks: many of the project maintainers and contributors are attending the Build Meetup conference all day today and tomorrow. (We're also presenting two talks there tomorrow about Pants.) Just want to mention in case replies seem slower than usual for a couple days.

Hi all! I'm one of the organisers of the Build Meetup conference and wanted to come along and say hi, Thanks so much for all the support that the Pants community has given to Build Meetup and for the great talks. It's been ace 🙂

Congrats to @steep-breakfast-98857 for merging Poetry support! He did an awesome job adding a

poetry_requirements

macro so that Pants will map your

pyproject.toml

into a bunch of

python_requirement_library

targets, similar to the

python_requirements

macro. See https://github.com/pantsbuild/pants/pull/12174 for some fun parsing code 😄 Will be released very soon in Pants 2.6 🎉

Hi, not sure where the best place to ask is but what's the process for getting

pantsbuild/example-python

updated to a newer pypi release? A fix needed for

remote-apis-testing

recently landed in 2.6.0.dev2 & 2.5.1rc3 and I'd love to get it incorporated! :)

I am looking at the

list

goal documentation and see https://www.pantsbuild.org/v2.6/docs/reference-list#section-provides. Running

$ ./pants list --list-provides=True ::

does print names from the

python_distribution

and from the

provides=setup_py()

in the root

BUILD

file

//:python_distribution-name setup_py-name

The help says:

List only targets that provide an artifact, displaying the columns specified by --provides-columns.

I can’t find docs on

--provides-columns

argument — is it a refactoring leftover or something that is coming that’s not available in the public docs yet? Many thanks.

Is there a way to inform pants on how much of the first-party version I'd like it to use when using ``--setup-py-generation-first-party-dependency-version-scheme=compatible` ? I'd like to have things setup so that minor versions are considered compatible, but it looks like if my first party dependency specifies a patch version that the dependent distribution ends up with

~=1.2.3

whereas I'd like it to be

~=1.2

Just started a brand new repo in pants and I am not seeing output from pytest? I just see that the test run failed but no info on what actually happened or error message. Any ideas what might cause this?

Enjoying Pants? Terrific! That's the goal: developer joy. Remember that the best way you can help Pants grow is to talk about us and recommend us. Tell other people why you use Pants, and how it benefits you. Thank you for contributing to Pants community!

Hey folks, I’ve submitted a few simple fixes to the docs and using the Readme project was fine, but suggesting edits without seeing the preview makes me worry I submit the text malformatted. Also, there is no way to see my submissions. Perhaps it’s a permission thing that a non-team contributor can’t see the preview of an edit or list the submissions. Is anyone outside of the core Pants team able to preview the suggested edits?

Hi! Does anyone here have a good structure/pattern for a 

Python + Docker + GCP

 Monorepo architecture!? Curious to see how others have done this 🙂

Hi there! We’re looking to move from multi-repo into a monorepo with pants, however I’m struggling to match pants with our current dev cycle which is very Docker heavy. We have a command that spins up a container with its source code, as well as any supporting containers (i.e. db), and then it runs all tests in there. As far as I understood, pants doesn’t have any current integrations with Docker so I’m wondering how I could achieve this workflow with minimal effort. I’m thinking something like

src/project1
src/project2
src/lib/lib1
src/lib/lib2
...

where

project{n}

contain independently deployable applications, and

lib

contains shared libraries (projects can’t import each other’s code). Each

project{n}

has its own

Dockerfile

and

docker-compose.yml

. Now I probably also need a “global”

docker-compose.yml

that is extended by the one in each project. The difficulty now is how to follow Pant’s philosophy in this setup. For example, in pants I can change any file, and it will figure out what things need to be run. But in the setup I just explained, this won’t work, since pants doesn’t know which databases a particular project or library might require.

Hi there! I’ve been happily running pantsbuild 2.5.1rc2_py37 in a monorepo but have an occasional/random

Resource temporarily unavailable

Exception - what would be the best way to debug this?

Because people use Docker in different ways until now people have written their own Pants plugins to support their specific needs. But it does sound like we now have enough potential use-cases to spec out generally useful first-class Docker support!

Is there a way to easily connect Pants builds + Docker to GCP Cloudrun?

I am looking at how Pants could support running tests against multiple Python versions. I have normally done it using

tox

before using Pants. Pants doesn’t mention

tox

in the docs and I didn’t find any related issues on GitHub. The

interpreter_constraints

option (docs) will resolve to a single Python interpreter version (so

interpreter_constraints = ["CPython==3.6.9", "CPython==3.8.5"]

wouldn’t make sense). My use case is as follows. I generate two PEX files — one for Python 3.6 and one for Python 3.8. It works out nicely since

pex_binary

provides interpreter_constraints parameter, so I have two declarations of

pex_binary

(in the root

BUILD

file) each having a distinct Python interpreter version constraint. When packaging, I do see that each PEX file (after unpacking for inspection) contains the wheels for the target Python version. I have managed to create a requirements file with pinned transitive 3rd party dependencies with the versions of Python packages that work for both 3.6 and 3.8. Having two target runtime environments of course implies that it’s required to run tests both against 3.6 and 3.8 interpreter. However, the

test

goal works only against a single interpreter version:

[python-setup]
interpreter_constraints = ["CPython==3.8.5"]

Is there any way to run tests against multiple Python interpreters that I’ve missed being mentioned in the docs (without manually switching the Python versions in the

pants.toml

)?

Is there any smooth way to integrate Pants with GCP, specifically container registry and/or cloud run

Hi folks! I’m having an issue where a package I’m consuming from PyPI (via the

python_requirements

macro) has started including a module whose name clashes with a local module in my workspace, leading to dependency inference warnings like this (and other issues when both modules are used by a target):

22:22:22.84 [WARN] The target src/python/foo/health_score/ios/file_line_count_insight.py:ios_health_score imports `foo.health_score.health_score_check.HealthScoreCheck`, but Pants cannot safely infer a dependency because more than one target owns this module, so it is ambiguous which to use: ['3rdparty/python:foo-sdk', 'src/python/foo/health_score/health_score_check.py:lib'].

(

foo-sdk

includes both a

foo_sdk

and a

foo

module.) Is there any way exclude a specific module from a package? Some magic with a handwritten

python_requirement_library

target perhaps? Or am I better off renaming my local module?

Trying out the new poetry functionality but poetry_requirements seems to be not part of the python backend by default. Do I need to add a new backend?

$ ./pants --version
23:01:10.36 [INFO] Initializing scheduler...
23:01:10.52 [INFO] Scheduler initialized.
2.6.0rc0

./project-app/BUILD ./project-app/pyproject.toml ./project-app/src/app.py

poetry_requirements()

pex_binary(
    name="project-app-pex",
    entry_point="src/app.py",
    zip_safe=False,
)


python_tests(
    name="tests",
    sources=["test_*.py"],
    timeout=120,
)

$ ./pants run project-app:project-app-pex -lerror
23:03:12.60 [ERROR] Exception caught: (pants.engine.internals.scheduler.ExecutionError)
  File "/home/ehiggs/.cache/pants/setup/bootstrap-Linux-x86_64/2.6.0rc0_py39/lib/python3.9/site-packages/pants/bin/local_pants_runner.py", line 234, in _run_inner
    return self._perform_run(goals)
  File "/home/ehiggs/.cache/pants/setup/bootstrap-Linux-x86_64/2.6.0rc0_py39/lib/python3.9/site-packages/pants/bin/local_pants_runner.py", line 173, in _perform_run
    return self._perform_run_body(goals, poll=False)
  File "/home/ehiggs/.cache/pants/setup/bootstrap-Linux-x86_64/2.6.0rc0_py39/lib/python3.9/site-packages/pants/bin/local_pants_runner.py", line 190, in _perform_run_body
    return self.graph_session.run_goal_rules(
  File "/home/ehiggs/.cache/pants/setup/bootstrap-Linux-x86_64/2.6.0rc0_py39/lib/python3.9/site-packages/pants/init/engine_initializer.py", line 135, in run_goal_rules
    exit_code = self.scheduler_session.run_goal_rule(
  File "/home/ehiggs/.cache/pants/setup/bootstrap-Linux-x86_64/2.6.0rc0_py39/lib/python3.9/site-packages/pants/engine/internals/scheduler.py", line 533, in run_goal_rule
    self._raise_on_error([t for _, t in throws])
  File "/home/ehiggs/.cache/pants/setup/bootstrap-Linux-x86_64/2.6.0rc0_py39/lib/python3.9/site-packages/pants/engine/internals/scheduler.py", line 501, in _raise_on_error
    raise ExecutionError(

Exception message: 1 Exception encountered:

  MappingError: Failed to parse project-app/BUILD:
Name 'poetry_requirements' is not defined.

If you expect to see more symbols activated in the below list, refer to (<https://www.pantsbuild.org/v2.6/docs/enabling-backends>) for all available backends to activate.

All registered symbols: ['_python_requirements_file', 'archive', 'files', 'pants_requirement', 'pex_binary', 'pipenv_requirements', 'python_artifact', 'python_distribution', 'python_library', 'python_requirement_library', 'python_requirements', 'python_tests', 'relocated_files', 'resources', 'setup_py', 'target']

Oh, oopsies 🙂 you are right indeed. will hotfix and do a new rc today

python3.9.5, Ubuntu 21.04

I'm new to pants and going in the deep end with new bleeding edge features... do I understand that only the top level directories where requirements.txt or pyproject.toml will need the BUILD files? tailor seems to put them in most directories... do they need to be in like every dir like

___init___.py

Those BUILD files tell pants "here is some python source code for you to care about", so they are neccessary.

The BUILD file that represents requirements is different (same file name, different content...)

BUILD is just metadata that describes the structure of your codebase to Pants.

Hmm; I wrote a long description so can add more, but I'm having a curious problem with some tests and namespaced packages (pants 2.50, python 3.9). Bah, some description necessary anyway 🙂 I have three "namespaced modules", call them

a

(dir structure

a/ns/a...

where this

ns

contains

__init_.py

)_ as well as b and c (which look like

b/ns/b..

and

c/ns/c...

). root directories a,b,c have SOURCE_ROOT set and a BUILD for

python_requirements

, and all three

ns/X

directories have a BUILD for

python_library

. I will say that

b/ns

and

c/ns

don't have a BUILD because there are no source files there (including an

__init__py

because I didn't want it to conflict with

a

). Okay. AAaaaanyway, I have a few

python_test

targets that use

b

or

c

, and they seem to run OK (the

./pants dependencies

shows

b/ns/b/__init__.py

and relevant files, and the tests run). But I have one irritating test that isn't playing nice:

./pants dependencies

shows

b/ns/b/_init_.py

and all files that I think I'm importing, but running the test fails with the equivalent of

module/tests/test_file.py:2: in <module>
  from ns.b.submodule.submodule import Thing
E: ModuleNotFoundError: No module named `ns.b`

So I don't quite understand what's gone wrong. I've stared at comparable BUILD files to try and understand what's different. Is there a way to force rebuilding of the test pex just to make sure there's not a caching issue? Or something else I should look at?