snap <directory> is error prone

[Gustavo Niemeyer]

Having "cd $dir; snapcraft snap" and "snapcraft snap $dir" behaving completely different and producing completely different results is extremely error prone. The latter should be a command of its on. Something like "snapcraft snap-content $dir".

[Sergio Schvezov (sergiusens)]

I am in favor of this fwiw. I would really like to decouple things that belong more to the life cycle and things that are more of an out of band thing.

Take as another example the upload command (should a snap built with the snap command be uploaded without specifying a file? I think it should as we will know if it is indeed the snap you want to upload).

That said, I am not so sure we can change this and kill `snapcraft snap <dir>` as it would break our existing users and API (the cli API that is).
We can implement it and add a deprecation message to the former one though.

[Sergio Schvezov (sergiusens)]

I am marking as incomplete just to see where we prefer to go here.

[Gustavo Niemeyer (niemeyer)]

We can do a few things to prevent any major issues while fixing behavior:

1. Obsolete the behavior first rather than killing altogether

2. Detect the intention of the user by having a quick look inside the directory at hand and checking if a $DIR/meta/snap.yaml is there. If there's no such file, this is definitely not supposed to be packed as-is.

3. Show a bit fat warning when people use it with the old command expecting the wrong semantics. It can still work, but we should warn loudly and point them towards the new command.

[Oliver Grawert (ogra)]

whatever gets decided, please let me know *before* it lands, the live-build scripts currently use
"snapcraft snap $dir" for os and kernel snaps, so if the command name changes the scripts need adjustment.

[Gustavo Niemeyer (niemeyer)]

With the proposal above, your scripts would not break.

[Pat McGowan (pat-mcgowan)]

I just ran into this odd inconsistency, any plan to fix?
Comment #3 item 2 would easily resolve it