Remove advanced flags from python-repos subsystems

[asherf]

Currently, if you try to get help for this subsystem, ./pants help python-repos you will get nothing useful and the user needs to repeat the command with the help-advanced directive (happened to me right now).
My thinking is: It is somewhat pointless to have a subsystem where all the options are advanced, it makes sense if there are multiple options and some are advanced and some or not.
But I don't think we should allow options scopes that only have advanced options since it a little confusing to users trying to get help about it.

This is just an opinion, feel free to close this PR.

[jsirois]

@asherf you're getting burnt by the macos-10.15 brownout. Fix is in #16317.

[benjyw]

This is fine for now, to avoid the weirdness @asherf mentions.

A more general solution might be to show advanced help automatically if there are no non-advanced options.

I've been wondering what the benefit of the "advanced" concept is. Initially it was for "options more likely to be specified on the cli" vs "options more likely to be specified in config". Now with bash autocompletion we actually have a use for this distinction!

[Eric-Arellano]

I've been wondering what the benefit of the "advanced" concept is. Initially it was for "options more likely to be specified on the cli" vs "options more likely to be specified in config". Now with bash autocompletion we actually have a use for this distinction!

Hm, so then should we instead fix this by your suggestion right above?

A more general solution might be to show advanced help automatically if there are no non-advanced options.

[benjyw]

Hm, so then should we instead fix this by your suggestion right above?

Maybe? It's true that these are properly "advanced" options in the now-useful sense. I.e., we wouldn't want to bash-complete them, they would just be noise. Or maybe we do and my distinction is not significant after all? I feel like we could go around on that for a while...

But anyway, yeah, may be better to show advanced options proactively in such cases.

[Eric-Arellano]

We have A LOT of options. Now that we have autocomplete, I bias towards thinking the distinction is worth it. But I could be convinced.

[asherf]

I added #16352
but I still think this PR is viable since I think those options are not "advanced", at least not to me....
just my 2c.
but feel free to close this PR if it makes sense to keep these options as advanced.

[Eric-Arellano]

but I still think this PR is viable since I think those options are not "advanced", at least not to me....
just my 2c.

Given our definition of "is this likely to be set by everyday users, or only admins?", I think these would be advanced. Ideally everyday users don't have to think about indexes! Wdyt?

[asherf]

but I still think this PR is viable since I think those options are not "advanced", at least not to me....
just my 2c.

Given our definition of "is this likely to be set by everyday users, or only admins?", I think these would be advanced. Ideally everyday users don't have to think about indexes! Wdyt?

that definition makes total sense to me.