https://pantsbuild.org/ logo
#general
Title
# general
g

gorgeous-winter-99296

03/19/2023, 1:56 PM
Is there some method for branching on pants version in BUILD files? I've done the following as a macro:
Copy code
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:
Copy code
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",
)
b

bitter-ability-32190

03/19/2023, 3:05 PM
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?
Oh and I guess this is a macro you plan on exposing? Because otherwise BUILD files are pretty closely tied to the build root they are a part of which has one static pants version
g

gorgeous-winter-99296

03/19/2023, 3:10 PM
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.
Maybe Pants magically never has issues, but I've so far never used a tool that hasn't had one or more regressions or undocumented changes between versions.
(e.g. the goal is to gracefully handle
PANTS_VERSION=2.16.0dev0
if something is broken/needs upgrading/...)
e

enough-analyst-54434

03/19/2023, 3:17 PM
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.
g

gorgeous-winter-99296

03/19/2023, 3:27 PM
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 🙂
e

enough-analyst-54434

03/19/2023, 3:32 PM
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.
The fact you had to do crazy things to even get our pants test utils working out of repo was as concise an example of this Pants hacker skew as I can think of.
f

fast-nail-55400

03/19/2023, 3:46 PM
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
.
If the "What's New" in the release notes is confusing on that point, we can always just add a sentence explaining the deprecation.
Maybe we should expose the current Pants version as another value usable by BUILD files?
g

gorgeous-winter-99296

03/19/2023, 4:02 PM
Yeah; that'd solve my issues - I can replicate the version comparison in native Python.
As an aside @fast-nail-55400: The changelog is a bit inconsistent. In the prose part; it says
In recognition of these improvements, the
experimental_shell_command
and
experimental_run_shell_command
target types have graduated to no longer have the
experimental_
prefix; use
shell_command
and
run_shell_command
respectively instead.
But in the details it does clarify that they are being deprecated:
User API Changes
• Deprecates
experimental_run_shell_command
in favour of
run_shell_command
(#18266)
• Deprecates
experimental_shell_command
, replacing with
shell_command
(#18255)
b

bitter-ability-32190

03/19/2023, 7:19 PM
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 😅
f

fast-nail-55400

03/19/2023, 7:46 PM
@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.
g

gorgeous-winter-99296

03/19/2023, 8:55 PM
@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.
b

bitter-ability-32190

03/19/2023, 9:09 PM
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 🥰
3 Views