<https://pantsbuild.slack.com/archives/C046T6T9U/p...
# development
any ideas around how to do this while keeping the
--no-process-cleanup
equivalent short? … i guess that
--process-cleanup=none
isn’t that bad, but.
h
yeah
--process-cleanup=none
is fine
w
i may not be able to change it in place anyway though…
h
I think John has in the past done complex bool->enum deprecations like this before. It's awkward, but I think feasible
b
I never did look into cleaning options more past the declarative API. Perhaps this kind of thing should be better supported?
w
so, i’ve looked at this a bit, and i can definitely imagine having enabled and disabled default values of an enum. but i’m concerned that doing that would just end up introducing complexity that cannot easily be removed… you’d need a way to generically deprecate using the old/overloaded syntax for the option, or otherwise you’re stuck with something that’s hard to document and explain
1
it feels more like you’d want to have a list of option types sharing a name, which are parsed in order, each of which could be deprecated.
but… that’s out of scope for this exercise i think.
so: i think that i’ll go with a name change.
maybe:
--preserve-sandboxes=always,on_failure,never
… but don’t love it.
b
run
has
cleanup
. So
--process-cleanup=...
Oh LOL thats the existing option. Forgive me, still a bit sick and haven't had coffee 😅
🤦‍♂️
w
ditto… s’all good. Lou was grumpy last night for some reason, and now i am too.
h
--keep-sandboxes
is better than
--preserve-sandboxes
imo
👍 2
b
(I always have trouble typing "preserve")
h
I don't love having to change again what everyone's muscle memory is (used to be
--no-process-execution-local-cleanup
). But I do think
--keep-sandboxes
is more intuitive than
--local-cleanup
so, i’ve looked at this a bit, and i can definitely imagine having enabled and disabled default values of an enum.
I think this is more complexity than we want. I would encourage the bool option to solely be temporary, as we migrate to enum I bias towards that to avoid churn for users, but I also like
--keep-sandboxes
w
yea. i think rename with long deprecation (probably not even triggering yet in
2.13.x
) will be the path.
2
h
true,
removal_start_version
is a great utility added by @chilly-magazine-21545. You can still use
resolve_conflicting_options
or whatever I think