Scoped directives should not require the --power flag

[JD557]

Currently, publish directives like publish.name force the user to use the --power flag. I don't think this is a good decision

Say I have a library using scala CLI as a build system with my publish directives in a publish-conf.scala (as the recommended setup).

With this setup, I cannot simply run scala-cli build ., and am forced to run scala-cli --power build .. In fact, I believe this forces me to use --power in all commands.
This normalizes the usages of --power, actually incentivizing users just use scala-cli config power true, making the flag quite useless in my opinion ("when everyone is super, no one is", and all that).

On top of that, scala-cli publish already requires the --power flag anyway, so this is a redundant check.

I imagine this is also true for other directives, like the package directives.

Am I missing something? What do you think of changing this behavior?

[Gedochao]

Generally speaking, in the context of SIP, we mark all features separately with RFC tags (check https://github.com/VirtusLab/scala-cli/blob/9f9562062cc9a2a890e1afdc18a4ed802f9d6251/modules/specification-level/src/main/scala/scala/cli/commands/SpecificationLevel.scala)

This means all features individually are tagged as such (this includes each sub-command, option, directive and config key, separately).
Every feature tagged with RESTRICTED or EXPERIMENTAL requires passing --power if it's present in your build, anywhere.

The publish.name directive key is EXPERIMENTAL, so if it's present in your build, you do, indeed, need to pass --power. Even if you aren't publishing, your build definition uses something our spec considers experimental, so it's hard to go around it.
Think of it as a piece of bureaucracy enforced by the SIP - Scala CLI has been approved to become the official Scala runner, but this makes us have to abide by certain rules when adding features outside of the official runner spec.
It's a workaround, in a way - by hiding stuff behind --power we can release things without them immediately being approved by SIP for as long as they are, indeed, hidden.

Now, whether it makes the --power flag a redundant check? I'm not so sure about this part. If your build includes publishing directives, then you should already have the power key configured to true permanently, since you are using the larger Scala CLI feature set, and not just the official runner SIP approved ones.

When an EXPERIMENTAL feature is being used, a warning is being printed even with --power (although the warning can be suppressed by the user). So it's still unlikely for a user to rely on a feature that's experimental (and thus not necessarily stable) without knowing about it.

RESTRICTED in turn is maybe less obvious, as we do consider RESTRICTED features to be stable and production-ready, as a rule. Features tagged as RESTRICTED are stable and mature features which haven't been yet included in a SIP (but might in the future), which means SIP requires as to hide them behind the --power flag.

[JD557]

Thanks for the explanation. That indeed makes things more complicated, so I agree that it's best to keep the current behavior (which sounds quite principled) instead of adding exceptions.

If your build includes publishing directives, then you should already have the power key configured to true permanently, since you are using the larger Scala CLI feature set, and not just the official runner SIP approved ones.

I think you are right. I was writing a rebuttal to this, but I think I was just misinterpreting the --power flag more as sudo and less as experimental/.