`space init` should not override profile

[sttts]

What happened?

Today space init overrides the up profile. The up profile is most likely the cloud profile for many ppl trying Spaces for the first time. In any case, it means dataloss if there is a profile already.

The expected behaviour would be to add a new profile under another name.

How can we reproduce it?

$ up login # log into cloud
$ up space init

After this the cloud login is lost.

What environment did it happen in?

Latest master version.

[AlainRoy]

For what it's worth, this mirrors the behavior of up login. I believe that will overwrite the current profile as well. Both commands take a --profile command so that you can set a specific profile if you prefer. I think they're consistent commands.

I'm not against changing the behavior, but I think it requires a little thought. If someone does "up login" a few times, should they end up with a new profile for each time? That could cause too many profiles to be created.

I think this is worth a bit of thought before we change the behavior.

[sttts]

The difference is that login is called to create get a working (cloud) profile. In space init it's a side-effect nobody expects or thinks about.

[sttts]

Actually, if we made profile creation interactive with a [Yn] prompt, it would also be fine. But +1 for "worth a bit of thought".

[AlainRoy]

it's a side-effect nobody expects or thinks about

Maybe? "nobody" is a strong statement. But whether you're right or I'm right, I think it points to stepping back and thinking through the desired interface.

[sttts]

The easiest would be: refuse init if the passed or defaulted profile name already exists.