I'm having trouble writing an "in-repo" plugin for a custom codegen. I have put it under

pants-plugins/tutugen

which contains a

register.py

file and a

BUILD

file. First, I'm not sure what I should put on the BUILD file. I read about python_source, python_requirement and pants_requirements. I'm not sure which ones should go in the file. Then, the plugin requires a 3rd party lib named

tutu

. If I try to exec any pants commands, I get a

No module named: 'tutu'

error. I'm not sure what is missing :-/

Still in my plugin, I have a rule which has access to a target. Inside there is a field named "policies". I can see the data if I logger.info(mytarget) but I can't access it. mytarget.policies or mytarget["policies"] don't work. How can I access that field?

Also, is there a doc about how to create a target generator?

Last one for the day. I can't use my new codegen module. I have a

python_awslambda

target and it seems I can't make it depend on the generated files coming from my new codegen target. If I make it depends on the codegen source files via a

resources

target, the source files are added on the lambda. But if I make it depends on the codegen target, nothing is added. If I do a

./pants export-codegen ::

, the files are generated at the right place. I'm not sure what I am missing here 😕

Typically your

python_awslambda

target would depend on some source files in a

python_sources

target and those would in turn depend on generated sources?

Is that not the case here?

That

python_sources

should depend on the codegen target (either implicitly via dep inference or explicitly via

dependencies=

) and the right thing "should happen"

To clarify, this is a custom code generator in your plugin?

yes, it's a custom codegen

my tutu codegen 🙂

it generates a yaml file so pants can't really infer the deps. So I referenced the codegen target on the dependencies of the

python_awslambda

target

I tried with

protobuf_sources

and in that case, the result is added to the lambda. So I suspect my custom codegen module but I don't know where to look at. If I run

./pants export-codegen ::

, the files are generated at the right place, so I'm not sure why nothing is added to the lambda

is it possible to get intellisense going for

BUILD

files via vscode (i.e. autocomplete of target documentation and such, as if it was an actual python file with some globals in scope) ? and if so, how would one go about that? .. 🙏

Hello, I'm still stuck with my codegen plugin and my head hurts. I pushed an example what I do there: https://github.com/Gaasmann/monorepants There, there is some files that are under

py/projects/cards/ext-config/something

that will be used for generating files. The yaml files use the

tutu

plugin that is under

pants-plugins/

and I also added a .proto and a resource file not going through codegen for comparing. If I use

./pants export-codegen ::

everything is generated. If I use

./pants package ::

, the lambda only gets the .py generated from the .proto file and the resource file.

% monorepants/dist/py.projects.cards% unzip -t lambda.zip
[...]
    testing: PEX-INFO                 OK
    testing: __main__.py              OK
    testing: ext-config/              OK
    testing: ext-config/something/    OK
    testing: ext-config/something/a-resource-file   OK
    testing: ext_config/              OK
    testing: ext_config/something/    OK
    testing: ext_config/something/something_pb2.py   OK
    testing: turbocorp/               OK
    testing: turbocorp/cards/         OK
    testing: turbocorp/cards/__init__.py   OK
    testing: turbocorp/cards/core/    OK
    testing: turbocorp/cards/core/__init__.py   OK
    testing: turbocorp/cards/core/deck.py   OK
    testing: turbocorp/cards/entrypoint.py   OK
    testing: turbocorp/cards/game.py   OK
    testing: LAMBDEX-INFO             OK
    testing: lambdex_handler.py       OK
No errors detected in compressed data of lambda.zip.

Does someone have an idea why my generated yaml files don't make it to the zip file?

Is it expected that

--no-process-cleanup

doesn't work for running

shunit2

tests? I've been trying to debug some fixture files not being included in my tests, but I don't actually end up with any preserved sandbox directories.

Hello, I am new to pants and trying to monorepo my backend services built using FastAPI. But FastAPI internally required Pydantic. And resolving this dependency has been an issue for me for the past 1 week. it runs on my mac, but when I create a docker_image and then run the code it gives the following error:

No interpreter compatible with the requested constraints was found:

  A distribution for pydantic could not be resolved for /usr/local/bin/python3.8.
  Found 1 distribution for pydantic that do not apply:
  1.) The wheel tags for pydantic 1.9.1 are cp38-cp38-macosx_10_9_x86_64 which do not match the supported tags of /usr/local/bin/python3.8:
  cp38-cp38-manylinux_2_31_aarch64

Attached: whitepaper "DevOps Setups: A Benchmarking Study 2021"

I’m having a dumb moment… Trying to exclude a tests [source] directory from mypy in pants.toml. What’s wrong with?

[mypy]

args = [“--exclude tests/“]

okay, so i’m trying to develop my first plugin (daunting 😅), and yet again i’m asking for IDE support (mostly for documentation purposes), and since this is now just regular python3 code that should allow for using all the bells and whistles of whatever python language server integration my editor has? … but, i sort of expected more paths to show up after enabling python + plugin development plugins …

❯ ./pants roots
pants-plugins

where do i point my editor to to get the proper path for the current version of the pants python libraries? as i understand it pants bundles it’s own python somewhere digging around in

~/.cache/pants

i’ve found

~/.cache/pants/setup/bootstrap-Darwin-arm64/pants.bA7ZRm/install/lib/python3.9/site-packages/

…. which looks promising, but is there some established way through a similar command to get to this path without manual spelunking? and is this enough to get lsp support? let me iterate — i’m in no way a python developer 😆

Can pants (in future) do third party dependency management like poetry does with

add

,

remove

or

update

? I suppose this won’t generalize across multiple languages.

📣 Do you use Rust in your codebase? Do you wish you could apply Pants features like dependency inference to it? Pants team would love to add Rust support! Pants V2 engine is written in Rust, and it's a language dear to our hearts. Toolchain, the lead sponsor of Pants, is seeking organizational partners or sponsors to join with us to make that happen. If you're interested in getting your organization involved, hit me up. Let's make it happen. 📣

one last question for me for today (mayhaps 😅) i’m looking to add support / dependency inference for a language which has some fairly strict rules regarding imports — i’ll probably break my neck in trying to do so, but — is there any good examples i should be looking into for understanding what is needed there? .. i guess shell might not be the worst starting point, to try and understand how that plugin is structured, and where the

:sausage:

is made … 😆

Exploring pants for two weeks, I made a example repo for multi-projects based on pyspark: https://github.com/da-tubi/pants-pyspark

Has anyone tried running Pulumi with the code managed as part of a Pants repo? More details in thread…

I would like to work on a linter plugin that would verify that dependencies between targets are allowed. For example, our domain layer shouldn't depend on the application layer. Another example, one micro-service should only depend on the contract of another micro-service but not the code. So the idea is to use some kind of wildcard on both sides of the rule. For example:

dependency_rule("/modules/core/application/*", allowed=["/modules/core/domain/*"])

What would be the best matching utility within pants for that?

Different output/error level for different pants goals using

changed-since

when no source files were changed. Please see 🧵

I was hoping to reduce our CI time and hence used the

changed-since=main

when running test. But then this messes up with our coverage threshold and hence the CI fails. Is there any solution for this?

Hey all. I’m seeing a strange issue in the Python monorepo I’m working in. We have several formatters setup (autoflake, black, and isort) and I’ve run them over the whole repository with

./pants fmt ::

. After this,

./pants lint ::

shows the linters are satisfied with the work they’ve done. However, if I then run

./pants lint subdirectory::

some of the linters complain that they would make changes (

isort

in particular). Any idea what’s going on here?

./pants tailor

succeeds without issue so the BUILD files look to be in order. ’m seeing a strange issue in the Python monorepo I’m working in. If I run

Hi all, I have my third-party dependencies for a Python package specified in a

pyproject.toml

file, using Flit to build the sdist/wheel. Is there a way to set a

python_requirements

to read the

pyproject.toml

file, when I’m not using Poetry? I saw that Pants supports PEP 517 to build the distribution, but I’m curious if it can also single-source the external dependencies. Thanks!

I have an extremely ostentatious proposal on how we might shift the paradigm of Pants and user's understanding of dependencies that I'd love feedback on. Ultimately my goal is to fix several issues that get brought up often that stem from the fact that our code makes assumptions about the types of targets in the

dependencies

field, and therefore falls short when presented when unexpected targets. I encourage everyone to read it, reflect on it, and comment with thoughts. It's an ambitious proposal (and will take a community effort to implement if agreed on) so I'm also going to explicitly ask readers to read the whole thing before commenting, and comment from a place of collaboration (and not from a place of challenge). The TL;DR is: 1. shifting from one monolithic

dependencies

field to several more specialized dependencies fields (e.g

file_deps

,

typecheck_deps

) 2. Treating the "file" as the root understanding of most dependencies