Add --yolo option

[quinchs]

Summary

as discussed in discord there should be a --yolo flag thats short hand for --non-interactive, --allow_empty, and --allow_unsafe, this PR adds exactly that.

[colinhacks]

I like this idea unironically.

[tailhook]

Option is added, but it doesn't do anything, except blocking other options in this PR :)

What's the use case for --allow-empty here? If you want "just apply the schema" then empty migration is not something useful. We might better return with success exit code but without creating a migration in --yolo mode.

(I think --allow-empty was added for completeness, because there is such an option in git, but might be a little bit useful for writing (possibly data) migrations manually; although, I think we need a better tool for them)

[quinchs]

Option is added, but it doesn't do anything, except blocking other options in this PR :)

Testing locally it has the same effect as specifying all flags

What's the use case for --allow-empty here?

For completeness, it can defiantly be removed

[1st1]

Sorry for being party pooper here, but i'm -1 on calling it "yolo" no matter how funny it seems to be now.

[tailhook]

Option is added, but it doesn't do anything, except blocking other options in this PR :)

Testing locally it has the same effect as specifying all flags

This shouldn't be the case. We automatically apply that for the first migration, maybe this is what you've tested it with? (otherwise we have a bug somewhere in our clap generator, I'll take a look)

Sorry for being party pooper here, but i'm -1 on calling it "yolo" no matter how funny it seems to be now.

I think we can just assume --non-interactive in --allow-unsafe? (because latter has no action in interactive mode anyways).

[elprans]

IMO we should just add a short option for --non-interactive, e.g. -y and -f for --allow-unsafe, so instead of create --yolo you'd type create -yf

[lostfutures]

honestly --yolo is much more accessible & clear, it implicitly makes clear what the consequences of the command are, in contrast to "-yf".
100% of people would instantly know the implications of --yolo, while 0% would instantly know the implications of -yf ( & they would forget it, while no one would forget what --yolo implicates )

Yolo just perfectly encapsulates the intentions of a command containing --non-interactive, --allow_empty, --allow_unsafe.

Also, never forget where the name of the programming language "Python" is coming from:

"Sorry for being party pooper here, but i'm -1 on calling it "Python" no matter how funny it seems to be now."
Thus in an alternate universe Python was instead given a more boring 'professional' name "P++", but never gained popularity and was quickly forgotten.

If Ronald Reagan were still alive today he'd probably say: "🇺🇦 Mr. Selivanov merge this Pull Request!"

[1st1]

100% of people would instantly know the implications of --yolo

I see the point, but I don't agree that 100% of people would instantly understand everything that it does just by looking at its name. E.g. I would still have to check with the docs. Moreover, overarching names like this seem intuitive at first, but imagine that in the future we want to include another option/behavior to --yolo because...it would make sense given the name. We might not able to do it, because that would be technically an incompatible change. So you'd end up teaching people about --yolo --some-other-annoying-flag etc.

In general, it's a bad idea to use non-technical jargon in API design. It rarely ages well, and I don't want our core tool chain to evolve into something barely comprehensible like PHP standard library. And it's not a popular approach to naming in other tools either, otherwise instead of git push --force we'd have git push --yolo.

/2c

[lostfutures]

I can see your viewpoint, but I respectfully disagree. Every word is made up and some people might perceive "technical jargon" to be 'annoying' while perceiving familiar language as more inclusive and useful.

Value judgments are points that people will differ on, but from a purely pragmatic point of view, I can guarantee you that when I teach 100 students about edgedb and they see me using "edgedb migration create --yolo" it will be infinitely more intuitive and familiar to them than using some obscure string of characters where they get confused and are not even sure if the order matters or what the intentions of the obscure flags are.

Technical jargon was also once non-technical annoying words which through usage became technical jargon.

It's your call Yury, do what thou wilt or dare I say, yolo.
P.S: I'm going to use git push --yolo from now on instead of git push --force sounds less aggressive and much more fun. Getting stuck in old patterns of thinking is not necessarily a breeding ground for innovation, just because people always used to do it some way doesn't mean it's the best way to do it.

[i0bs]

There are plenty of words with aberration to technical meaning used in today's devtools. I believe --yolo perfectly captures the scope of what's being requested and adds an unique part to EdgeDB that makes it stand out a little more than others.

You can't tell me "yeah I use MySQL, but have you ever yolo'd an EdgeDB?" does not sound poggers

[1st1]

Alright, alright, I admit "but have you ever yolo'd an EdgeDB?" has something in it. @elprans seems to also be OK with this. Let's add it. Although, we should also support -y as an alias for --yolo and it shouldn't include --allow-empty as @tailhook pointed out.

[quinchs]

Let's add it.

I think the current changes I've made does in fact do nothing except add it as a valid flag, for implementation properly imma leave that up to tailhook as I suck at rust 👀

[i0bs]

To further clarify, --allow-empty is a pre-emptive flag so it makes sense for it to not be required in the preset. I would like to ask though if -y is intentionally meant to be lowercase, as most single-lettered flags are uppercased like -Y.

[tailhook]

In nightly, we have edgedb migrate --dev-mode and (edgedb watch). They are not the same thing as edgedb migration create --yolo. But I think this is what was --yolo's primary use case.

Please try new watch/dev-mode workflow. And feel free to reopen describing the use case that doesn't fit that workflow.

Edit: Note: both --dev-mode flag and watch are hidden now. And watch will appear in the tomorrow's nightly.