Is there some method for branching on pants version in BUILD files? I've done the following as a macro:

def pants_at_least(version: str) -> bool:
    pants = __import__("pants")

    return pants.version.PANTS_SEMVER >= pants.version.Version(version)

But it's clearly wrong since I have to "force" the import to avoid the guard rails. My end-goal is to enable early adoption/testing of future pants versions in CI. Below is an instance from my open OCI backend where this would be useful in my examples directory:

empty_base = "//:empty"  # see [oci].empty_image_target

# using pants 2.15+ there's an built-in for empty bases, but before that we need to declare an empty image to use:
if not pants_at_least("2.15.0.dev0"):
    oci_image_empty(
        name="empty",
    )
    empty_base = ":empty"

oci_image_build(
    name="with_empty_base",
    base=[empty_base],
    packages=[":example"],
    tag="latest",
)

Hmm I wouldn't think

__import__

existed. Honestly it kinda works to think about BUILD files as Python the language, but not the runtime or ecosystem, or library IMO. To your question though, that looks eyebrow raising, can you share the use-case a bit better? A custom plugin that needs to support multiple pants versions I assume?

Yes; in the example it's so I can have examples that work for all versions I support. But in general I'd want to test/early adopt future pants versions in our internal repo. But I imagine things like

experimental_shell_command

won't have a deprecation period (at least it's not mentioned in 2.16.0 changelog right now afaict). I'm going to guess especially our internal plugins might be a bit fragile and require some finagling... and I'd rather catch/handle/triage early than deal with it when we bump Pants. This isn't something I plan to expose via my plugin, just a utility. I'm really hoping for a better way - I'd just copy this between all the repos if there's no sanctioned way.

We've been very poor about all this Tom. You're thinking ahead of the project. We've punted on API stability and testing across versions and need to correct that at some point.

Oh no, that's not the message I want to send. I'm just cynical from other tools 😉 I've had nothing but a good experience going from 2.13 to 2.14 (and to 2.15 in some repos). I'm probably a bit of an edge-case in terms of workflows - I work mostly on my own on the ML infra, running a fairly large monorepo with a dozen custom plugins... I'm hyper-optimizing for my own sanity 🙂

It's definitely the message I want to send though. We have been pretty Pants hacker skewed so far. We'll need to transition to a more user focused skew soon. Presumably ~2 years is enough to shake out API and start stabilizing so that true 3rd party plugins have a basis to grow on. We're still in a state where we don't support this well. You are forced to do what you're doing or else move the plugin into Pants so it gets automatically maintained by CI effectively. Not awesome.

But I imagine things like

experimental_shell_command

won't have a deprecation period (at least it's not mentioned in 2.16.0 changelog right now afaict).

experimental_shell_command

is still valid in 2.16.x. It is just a deprecated name for

shell_command

.

Yeah; that'd solve my issues - I can replicate the version comparison in native Python.

On one hand I don't like to think about branches in BUILD code because that's a huge red flag (not that your code is bad, but somewhere there's a fundamental disconnect). On the other hand the version in build files would be helpful to embed in certain strings (like a docker tag maybe). So I'm torn 😅

@gorgeous-winter-99296: before the semi-colon probably just needs: and are now deprecated and will be removed in 2.17,x; please transition code to use

shell_command

and

run_shell_command

respectively before then.

@bitter-ability-32190 Agreed in general, and I don't necessarily think we should make it too easy. But I don't think we can prevent people from parsing the string once it's there. I don't know when things like

%(env.FOOBAR)s

are expanded.

Oh yeah once we expose it I expect any and all use. What worries me is then people don't have a reason to be vocal like you do here, helping us understanding the struggles of those without our blinders. All this to say, I'd love to have this, albeit for different reasons. And please be vocal about your pain points. Bonus points if you wanna join us contributors. we love contributions 🥰