I found the tip to use

pants_requirement

for plugins to be a bit too narrow for our use case. Locking down each version of the plugin to a single pants version is a bit hard.. I’d like a little more flexibility, so I opted for:

#pants_requirement(name="pants", dist="pantsbuild.pants")
python_requirement_library(
    name="pants",
    requirements=["pantsbuild.pants >=2.6.0, <3.0"],
    module_mapping={
        "pantsbuild.pants": ["pants"],
    },
)

Instead.. sure enough, if there are breaking changes before 3.0, we’ll have to address them, but this will at least not require us to release a new version of the plugin for every pants release. Am I missing something, like, do I shoot my self horrible in the foot by doing this? (it is not a in-repo plugin, but stand alone, pushed to a cheese chop registry)

Sorry no one replied to this! I started looking into this as part of https://github.com/pantsbuild/pants/pull/13510. I think we should redesign this macro / target generator

pants_requirements(
   name="pants",
   testutil=False,   # default is `True`
 )

./pants list :
//:pants
//:pants#pantsbuild.pants
//:pants#pantsbuild.pants.testutil

For now, Pants only has two distributions, unlike v1 having dozens of them. If that changes in the future, we can do things like add

extra_dists: list[str]

. -- The version part is tricky..Pants's API is not stable between each major release, and can even have breaking changes between minor releases. But, the risk of a break is much much lower between 2.8.0 and 2.8.1 than it is 2.8.0.dev0 and 2.8.0.dev1 I'm thinking we could do a few things.. 1. Let the user set what they want the version to be, like

version="==2.{minor}.{patch}"

and

version=">=2.{minor}.{patch},<2.{minor + 1}"

2. Make our default more complex. If you're on a dev release, you have to use that exact dev release. If you're on an rc or stable release, you can use any version within that minor release I think I'm leaning towards #2, #1 is too hard to implement e.g. needing to use

eval

for that

minor + 1

template language. And it's overkill, you can do the explicit thing like you're doing