hey, just ran into this: 1. When I run a test that has failures the failing test that uses the testing.postgresql module the test hangs 2. When I run that same test with

--test-debug

then it completes. albeit with the test failures 3. When I get the tests to pass running w/out

--test-debug

works

Hi. I’m a pantsbuild newbie (quite experienced with normal pants 👖 though 😉 ). There were some teasers about cython in the documentation, but I couldn’t find any actual plugin code. Our current monorepo uses both Cython and f2py. Are there any examples of the cython plugin and are there any plans for broader support for C/fortran extensions?

Invoking w or w/out pantsd doesn’t seem to make a difference

Hi. We have a large python-django monorepo. Bazel and Pants are being considered now. I would love to understand why pants is better suited for python when compared with Bazel. I have seen people saying this (example) but want to articulate this better internally. Thanks

Our tests are failing in some places due to this error, any way around this?

Exception message: Package SourcePackage('file:///mnt/workspace/.pants.d/python-setup/resolved_requirements/CPython-2.7.17/watchdog-1.0.2.tar.gz') is not translateable by ChainedTranslator(WheelTranslator, EggTranslator, SourceTranslator)

Also I’m not sure why it’s using py2.7 since we have py3.7 specified

(This is happening during the

clean-all

target)

hey so just wanna give a big thanks to all of the pants devs for all their help. We’ve hit a few roadblocks over the past several weeks, especially with the 2020-resolver (in which I even submitted a bug report about it not working for py2). There was a moment of despair last week when requirements building times were very slow, like unacceptably slow. After further investigation, it turns out the slowness was with the py2 2020-resolver. Curiously enough, with the same set of requirements, the py3 2020-resolver was just as fast as py2+legacy-resolver. To give a few numbers of a cold cache startup time • Pants v1.25 Baseline 1m47.436s • Pants v2.2.0 PY2 + 2020-resolver 5m14.671s • Pants v2.2.0 PY2 + legacy_resolver 0m56.745s • Pants v2.2.0 PY3 + 2020-resolver 0m58.757s • Pants v2.2.0 PY3 + legacy-resolver 0m59.575s While 5m might not seem too bad (this ^^ was for a relatively simple package, some of our bigger pydata type packages were taking 30m+ to resolve!) After much hand-wringing, the solution was to use the legacy-resolver plus the global constraints file. Using the global constraints file meant bumping incompatible dependencies in various project code and doing a bunch of botocore version manipulations (aioboto3+aiobotocore+boto3+botocore have very awkward pin ranges amongst themselves). We view the legacy-resolver + constraints as a bridge to get us immediately on pantsv2 and then from there update our code completely to py3 so we can jump onto the 2020-resolver. (I haven’t done further py3+2020-resolver testing on larger packages so there is definitely an assumption I’m making here, and it could be the dependencies in that test target just required less backtracking for py3) In any case, what was taking 31m on a 16 core build server to test-the-world on a cold start with the 2020-resolver now with (legacy-resolver + constraints) takes 6m. And with a warm start we can test-the-world in under 2m. This is huge. We can literally test everything on every commit if we wanted to instead of doing incremental tests. And I imagine we can further reduce that time on beefier machines due to the parallelism of v2. So, big thanks to you all for all the work you put into v2!

When trying to do a pants package of a binary that doesn’t specify an explicit interpreter_constraint but relies upon pants choosing the min version in the global interpreter_constraints it seems that pants is choosing to build the requirement set for all interpreters found on my system. With ps I see that pip is running for 2.7.17, 3.6.9, 3.8.6 and 3.9.0 which are all versions i have installed with pyenv. But this package should only choose 2.7.17 since one of its deps is py2 only. I caught this because pants was throwing an exception building the wheel for the py2 only package. pants repl and pants test correctly constrain to the 2.7.17 interpreter I’m on 2.2.0 I can workaround this by constraining explicitly in the target.

https://twitter.com/pantsbuild/status/1356330147503251456 Pants' Rust engine and deep support for parallelism and cancellation enable even faster incremental builds via "speculation"! Check out the new post on the blog: https://t.co/ikTTeFaXl8 #python #monorepo Twitter

https://twitter.com/tokio_rs/status/1356367314107523074 Pants Build retweeted: This is a great, in-depth, write out of how Tokio and #rustlang’s async model helps them support parallelism with g… https://twitter.com/i/web/status/1356367314107523074 Twitter Pants' Rust engine and deep support for parallelism and cancellation enable even faster incremental builds via "spe… https://twitter.com/i/web/status/1356330147503251456 Twitter

I am trying to get flask babel translations to work. Not having any luck when using pants run. If I package the pex, unzip it, install it in a virtual directory, and then run it, everything works as expected. The BUILD file looks like this:

*python_library*(

name = "lib",

)

*resources*(

name = "translations",

sources = ["translations/**"],

)

*pex_binary*(

name = "bin",

entry_point = "<http://dash_campaign_status_report.app|dash_campaign_status_report.app>",

dependencies = [

":lib",

":translations",

"lib_dash:lib",

"lib_dash_security:lib",

]

)

If I run dependencies on the bin target I get:

dash_campaign_status_report/app.py:lib

dash_campaign_status_report/translations/en/LC_MESSAGES/messages.mo:../../../translations

dash_campaign_status_report/translations/en/LC_MESSAGES/messages.po:../../../translations

dash_campaign_status_report/translations/fr/LC_MESSAGES/messages.mo:../../../translations

dash_campaign_status_report/translations/fr/LC_MESSAGES/messages.po:../../../translations

dash_campaign_status_report/translations/messages.pot:../translation

First pass at a

./pants init

goal, that generates BUILD file targets for files that don't belong to any target: https://github.com/pantsbuild/pants/pull/11517

Hello 👋 I'm currently exploring Pants for our Python monorepo at work, and am running into some difficulties with the protobuf code generation part of things. I'm not sure if this is a bug, misconfiguration and misunderstanding on my part, or something else, so any help is appreciated. At a high level, we have some protobufs that we need to compile into Python code and into Rust code (compiling the Rust code is pretty straightforward and isn't part of what I'm looking for here; we're currently looking at Pants to help manage the Python side of our codebase.) Additionally, we'd like to package up the generated Python code into a distribution. Since the protobuf definitions are off on their own, and since we generate code for more than just Python, I don't want the generated code to be dropped into the same directory. I've looked at the documentation that suggests adding

python_source_root

to the

protobuf_library

target (https://www.pantsbuild.org/docs/protobuf#protobuf-and-source-roots). The documentation suggests that this will put the generated code in the specified source root; however, in practice it looks like it just creates that directory structure under

dist/codegen

. Additionally, dependency resolution for code that's using the generated

*_pb2

modules doesn't appear to be working (as judged by the output of

./pants dependencies path/to/the/file/that/uses/protobufs.py

Another wrinkle is that we'd like to create a Python distribution containing just the generated protobuf code, but I'm not even sure how to express that in Pants notation... particularly with the need to have

__init__.py

files created as well. There seem to be a lot of moving parts here, and I'm not sure if there's a bug or (more likely) some incomplete understanding on my part, possibly coupled with some inconsistent file layout choices in this repository. That's a lot of information, and I can provide more as needed... I just wanted to lay out my perception of the high-level issues as a way to hopefully start a discussion. Thanks in advance for any advice folks may have.

Is there a way to supply a

pytest.ini

when running

./pants test ::

? Or, failing that, a way to specify custom markers to the pytest run?

Bikeshedding opportunity: The goal I'm working on, currently named

init

, generates BUILD file boilerplate for you, and in the future may also suggest some pants.toml config, based on heuristics. @witty-crayon-22786 mentioned that

init

makes it sound like you'd only run this once, when you first integrate Pants, but in reality it's designed to be run in ongoing fashion, to generate BUILD file boilerplate for new and changed code as needed. So the bikeshed is, what is a good name for this goal? You'd run it as

./pants <name>

with no other arguments.

So

./pants init

is what it would currently be

Off the top of my head, other ideas include:

./pants gen

?

./pants setup

?

heh, i created a similar custom task for my org back in pants 0.x called

autopants

but yah i think i mapped it to the buildgen goal name

maybe

./pants boilerplate

?

./pants wizard

?

as an easter egg:

./pants t-shirt

<- now fully clothed

if the rule is that it must be idempotent, you could imagine it to be sortof like a meta-linter/“formatter” for the build

./pants fix

<- inspired by the scalafix project

Maybe a pants-related pun.

./pants belt

,

./pants suspenders

,

./pants fly

...