Does anyone know if we have a standard `migrate` s...
# development
w
Does anyone know if we have a standard
migrate
style goal for plugin code (or pants code)? We have something for updating build files, but is that basically it?
e.g. updates source code, updates pants.toml, etc
b
I think the new docs site uses
pants peek
to ensure it lists all built-in goals: https://www.pantsbuild.org/2.20/reference/goals
w
Ah neat, yeah, I think I recall that being mentioned in slack. I'm working on a remedial in-repo plugin migration tool (and possibly pants.toml option fixer), but I didn't want to re-do too much work (ie. we already have a build_files migration tool)
f
Migrate as in handle API changes?
Is that something which could run under
fix
goal?
w
🤷 In some ways, it is kinda like
pyupgrade
which runs as a fixer. I hadn't really thought about where it would fit into the ecosystem, as this is just a proof of concept for my plugins repo https://github.com/sureshjoshi/pants-plugins/blob/6ac20eec2065691932ec97e312b14c587926001b/pants-plugins/experimental/migrate/rules.py#L18-L49 We have the big call_by_name_migrate builtin goal, we have update-build-files goal which handles deprecations, etc. So, consolidation would be nice, but yeah, not there yet anyways.
@fast-nail-55400 Circling back to this - instead of putting it as a separate backend, what if it was coupled to enabling the
"pants.backend.plugin_development"
backend? As in, the act of having that backend enabled unlocks all the migration functionality anyways (regardless of what goal we use to actually run that functionality). So like, maybe if that backend is enabled, it'll occasionally do a deprecation check (which happens anyways), and then says "hey, you should run
fix
on those in-repo deprecations" or something. I had a slightly more robust idea which was to enable a
plugin
goal to add some super basic CLI add-ons to make life about 10% easier for in-repo plugin developers (
pants plugin init
,
pants plugin migrate ...
kinda thing)
e.g. from my presentation a while back, I was thinking of a CLI kinda like this - with maybe the specifics or the verbs changed, but basically a CLI-driven plugin workflow
f
+1 to opt-in for plugin development tools