https://pantsbuild.org/ logo
Join Slack
Powered by
Looking at <https://www.pantsbuild.org/v2.10/docs/...
# development
c
Looking at https://www.pantsbuild.org/v2.10/docs/reference-experimental_shell_command I’m pondering if it wouldn’t make more sense to have a 
shell_command
in a 
pants.backend.experimental.shell
backend rather than a 
experimental_shell_command
in 
pants.backend.shell
… ?
h
oh I like that. far less churn for users also
we can use the deprecated_alias feature on targets so that the migration isn't painful 🙂 update-build-files will auto-fix
c
Cool. I’ll address it 😉
Only drawback is that 
update-build-files
won’t be able to add the new 
pants.backend.experimental.shell
backend to 
pants.toml
though…
In this message:
Copy code
WARNING  pants.base.deprecated:deprecated.py:159 DEPRECATED: the target name experimental_shell_command will be removed in version 2.12.0.dev0.

Instead, use `shell_command`, which behaves the same. Run `./pants update-build-files` to automatically fix your BUILD files.
It would be good to also mention that the target has been relocated to a new backend. Hmm… or that’s a different thing…
f
Or have the experimental backend log a deprecation warning and import rules from the new backend.
So there would be “two” shell backends, one of which warns.
c
It’s the other way around, and simply using either backend should not warn.. but I’m introducing support for 
@deprecated
to also work for classes, so I can deprecated the target class from one of the backends.
so I can deprecated the target class from one of the backends.
Just realised this won’t work, as the target aliases is the same in both backends, so there’s no real telling them apart for the deprecation notice.
h
Well so there's two deprecations technically: 1) renaming the target 2) now requiring the experimental backend to be activated I still recommend using the 
Target
mechanism for renaming the target, so that 
update-build-files
works. Then you'll want to add something like a check inside the rule for evaluating experimental_shell_command that the experimental backend is in 
global_options.backend_packages
c
Precisely. It was my attempt to cut a corner there for the second point, where in my head I could keep the two targets separate (but alas, they’re not, due to the first point)
👍 1
So, thanks for the suggested next step, to check the backend config in the rule used for the shell command.. that makes sense.
❤️ 1
h
cool, and I recommend using that same pattern of having a dedicated rule for the deprecation like 
_MaybeWarnBackendNotActivated
so that we memoize the warning
➕ 1
4 Views
Open in Slack
PreviousNext
Powered by