strip phase name is not great

"bake"?

It sounds nice. I thought of "cook", and although "bake" is nicer, it still has that feeling of a long process. I was trying to find something else that would appear less like a long process and more like the lightweight step before the process is final.

The context we need to keep in mind is

    pull >> build >> stage >> $NAME >> snap

Which is a bit of a hard corner we've put ourselves on, in terms of terminology. Ideally we cannot use a term that conflicts with the feeling of build and stage (bake does that a bit), nor can we use anything that looks too final ("finish", etc).

Something like "apply", or "arrange", or "prepare"... "apply" is actually interesting. It is lightweight, not final, and gives a feeling of using something that was done before it. It would also fit well with "reapply" and "unapply", for the other ticket.

One more idea: part of the confusion on the clean behavior, reported on bug #1582469, was actually due to the mix up between "snap" the step and "snap" the directory.

So stage moves into stage/, strip moves into snap/, snap moves into .snap

Can we rename snap/ to something reflecting the phase name?

For example, how about:

  * stage => stage/
  * ready => ready/
  * snap => .snap

Another candidate: "prime". This might work well enough even if we keep the snap/ directory:

  * stage => stage/
  * prime => snap/
  * snap => .snap

Yes, I think aligning the destination with the command name is sensible.

Ah, nice. So how about this:

  * stage => stage/
  * prime => prime/
  * snap => .snap

Just take into account that any change on snapcraft's lifecycle at this point will be backwards incompatible. So we will have to either live with the two names until 18 with a deprecation message for the old one, or make a version jump to snapcraft 3 and push our existing users to the new version. And it all becomes more complicated if we don't just change the name of the command but also the behaviour of the step.

FWIW, I'm ok with any name you decide. Sergio will probably have a strong opinion here. He'll comment here during our weekly triaging next week.

Our goal is to make Snapcraft actually interesting as a platform, so we can reach a point where we would indeed be breaking lots of people with such changes. :-)

We can easily preserve the old command working, with a warning pointing to the new one.

I was never fond of strip and mentioned it while deciding it during the Budapest sprint so I all for deprecating this.

This is also the only case where we have a disconnect between the phase/step name and the directory it lands into.

Just for the record, from snapcraft 1.0 to 2.0 the rename was decided to be:

1.x 2.x
snap strip
assemble snap

And `snap` would take a dir to replace `snappy build`

History is history. :)

Can we go with "prime" for step name and directory, and then "snap" for creating the snap out of the prime directory?

On 24/05/16 01:37, Gustavo Niemeyer wrote:
> Can we go with "prime" for step name and directory, and then "snap" for
> creating the snap out of the prime directory?

+1

Sure thing.

So I am now implementing this change and just noticed that we still have inconsistencies. snapcraft.yaml takes the fileset keyword 'snap' which of course is != to 'prime' which would also be a point of confusion.

For histories sake, in a galaxy far far away this was once all aligned: snapcraft snap, snap dir, snap keyword in snapcraft.yaml.

Should we realign everything?

Does `snap try prime` feel good?

> snapcraft.yaml takes the fileset keyword 'snap' which of course is != to 'prime' which would also be a point of confusion.

That sounds clear and fine as-is. This is the content that will end up in the snap. The fact we have a "prime" step in between is a detail that does not make it inconsistent.

> Does `snap try prime` feel good?

It should really be "snap try" alone. We can find the right directory by starting from $CWD and walking up parent directories looking for "snapcraft.yaml", and then looking for "prime" in the same place.

> Should we realign everything?

That's what we are doing, I think. :)

Btw, if your suggestion is to replace "snapcraft prime" and prime/ by "snapcraft snap" and snap/, that sounds good, but then we get back into the problem of missing a verb for actually creating the "snap" file, and get back into the confusion of having "snap" meaning both the snap/ directory and the .snap file. This is precisely the background for this ticket, and why we're going into the prime+prime/ direction.

https://github.com/ubuntu-core/snapcraft/pull/543

This bug was fixed in the package snapcraft - 2.10+16.10

---------------
snapcraft (2.10+16.10) yakkety; urgency=medium

  [ Martin Wimpress ]
  * Correct autotools tests to use configflags (#521)

  [ Leo Arias ]
  * Run the integration tests against a local fake server when the user
    password is not in the environment. (#511) (LP: #1585023)
  * Move the login and logout methods to a client. (#518) (LP: #1586504)
  * Improve the config handling. (#519) (LP: #1586511)
  * Fix the one-time password login. (#529) (LP: #1586832)
  * Moved the download to the store client. (#530) (LP: #1586836)
  * Moved the upload to the store client. (#531) (LP: #1586836)
  * Updated the documentation about the icon. (#542) (LP: #1578231)
  * Improve the error message when a part binary is not found. (#541)
    (LP: #1582367)
  * Reenable the ROS demo for autopackage testing. (#520) (LP: #1588098)
  * Add macaroon support to login, upload and download. (#532) (LP: #1586910)
  * Set the no_proxy environment variable to access the local fake servers.
    (#546) (LP: #1588631)

  [ Stephen Stewart ]
  * nodejs plugin: Support configurable node version (#509) (LP: #1586104)

  [ Kyle Fazzari ]
  * Use correct cross-build packages for ppc64le. (#539) (LP: #1570944)

  [ Sergio Schvezov ]
  * Support zip files as source (#523) (LP: #1577062)
  * A nicer error message for incorrect stage-packages (#524) (LP: #1568131)
  * Support the assumes keyword (#525) (LP: #1586429)
  * Improve the template for snapcraft init (#528) (LP: #1575581)
  * Filter out *.snap from sourcedir (#535) (LP: #1575628)
  * Support setting a gopath for a go project from vcs (#538) (LP: #1583426)
  * Add a ticker for snapping (#540) (LP: #1582955)
  * Rename strip to prime (#543) (LP: #1582515)

  [ Didier Roche ]
  * Wrap plugin list output content (#534) (LP: #1587057)
  * Add snapcraft examples to scaffold getting started tour (#513)
    (LP: #1586137)

  [ Joe Talbott ]
  * Add support for parsing the parts wiki (#545) (LP: #1587583)

 -- Sergio Schvezov <email address hidden> Fri, 03 Jun 2016 13:37:58 -0300

Hello Gustavo, or anyone else affected,

Accepted snapcraft into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/snapcraft/2.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Tested in an up-to-date xenial system:
- Enabled the proposed archive
- Updated snapcraft to 2.10
- Made a snapcraft dir.
- snapcraft strip
- The step is executed and a deprecated message is printed.
- snapcraft clean
- snapcraft prime
- The step is executed and no deprecated message is printed.
- snapcraft strip
- The step is not executed again.
- snapcraft prime
- The step is not executed again.
- snapcraft clean -s prime
- The step is cleaned.
- snapcraft clean -s strip.
- Got an error message because the step is not valid. This is a bug, because the deprecation message should be printed here too. Reported in https://bugs.launchpad.net/snapcraft/+bug/1590256

We can fix this in the next release, so I'm marking the verification as done.

Thanks Chris!

> Got an error message because the step is not valid.

Good testing Leo! That's kind of a big deal-- the CLI is breaking without a major version jump. What's the point of introducing deprecation after you make a release where it's removed all together?

IMO, it's important but not critical. It was a mistake, not that we are renaming a feature without deprecation. We'll get it fixed with a regression test next week, and the impact I think is not enough to delay the release.

We'll make more mistakes. The cool thing is that our dev. process minimizes them and our short release cycle lets us find them quickly and make a decision about when to fix them.

This bug was fixed in the package snapcraft - 2.10.1

---------------
snapcraft (2.10.1) xenial; urgency=medium

  * Backwards compatible clean with strip (#556) (LP: #1590256)

 -- Sergio Schvezov <email address hidden> Wed, 08 Jun 2016 16:32:27 -0300