In the example given in the documentation about creating a customized

setup.py

plugin (https://www.pantsbuild.org/v2.0/docs/plugins-setup-py), reading from files (like a

README.md

file for the

long_description

field) is shown, but it looks like it's from a hard-coded path (e.g., just use the main readme from the repo root). I'm looking to create a couple Python distributions for different libraries in our monorepo, where each library has it's own readme file that I'd like to include. Is there a mechanism by which I can introspect the

python_distribution

to somehow figure out what the appropriate readme file for that distribution is? Specify a

resources

target for that file and make it a dependency? Rely on filesystem / naming conventions? Create a new custom

python_distribution

target with a dedicated key for specifying the path to the appropriate file? Something else? Thanks 🙇

You can add a custom kwarg to the original kwargs, then pop it

Can that argument just be a relative path (resolved relative to the BUILD file the distribution is defined in), or would / should it be a target defined on the file? Or would either work?

yep, it can be a relative path. Either relative to the BUILD file or relative to build root, whatever makes sense for your modeling if relative to BUILD file, do

request.target.address.spec_path

to get the directory of the BUILD file

Nice, I'll give that a shot. Thanks for this (and all the other help recently! 👍 )

Okay check out this new example I added to the bottom of "Part 2"! Please do suggest any edits either over Slack or by clicking the "Suggest edits" button in the top right corner 🙂 https://www.pantsbuild.org/v2.3/docs/plugins-setup-py#2-create-a-rule-with-your-logic cc @polite-garden-50641, who was confused about this same thing in December

This is a super common use case, we should consider having built in support for this

Yeah likely. Something like

long_description_path

on the target

For now, yes, just the long description. I may do some work with the version string later, but I'm just looking at the long description now.

Cool. The generalized mechanism we would provide would need to be relative to the build root, rather than BUILD file. If that mechanism had existed, would you have used it? Or you'd still use your custom plugin to make it relative to BUILD file? (We'll prob add regardlsss, but trying to understand how useful this would be)

🤔 If it existed already, then yeah, I would have made use of it. It seems a bit more natural to me at this point to resolve it relative to the BUILD file if possible, but I don't think that's a huge deal at the end of the day. One thing I'm looking at in my custom plugin is to see if there's a README.md relative to the BUILD, and if there is, just use it. Otherwise you can specify a path relative to the build root, and we'll use that.

Cool. Yeah, our mechanism has to be relative to the build root so that you can do things like point to a top-level project README, which Pants itself does for its distribution For yours, nice, I like it. Change the PathGlobs to not error (the default) when you're checking if it exists. Although you do probably want to handle the edge of the file being specified and there being a README at the same time. Maybe only fall back to README iff the kwarg wasn't specified, and then error if neither can be used

yup, exactly

And I'm sure that if core logic like this was in Pants already, it would be a relatively simple matter to use an even smaller custom plugin to get at those conventional behaviors we're after

Not quite, the plugin would be identical to before if we add this generic mechanism. The generic mechanism is only relevant to obviate the need for a plugin in the first place But yeah, sounds useful either way

🤔 I keep getting

Could not find a rule to satisfy Get(DigestContents, PathGlobs, ...

messages whenever I try to use a

Get

to make a digest, read contents, etc., even using patterns from https://www.pantsbuild.org/docs/rules-api-file-system or from the Pants codebase directly. Not quite sure what's going on... any pointers?

can you please share a gist of your plugin? what Pants version also?

Oh, if I call

Get

directly in a

@rule

function, that works, but calling it in an accessory method that I call from a

@rule

function fails unless I've already done that same

Get

call

we use: https://gist.github.com/asherf/6012037c1afe6940ca3ef2c421e8ee45

nice, thanks