strip phase name is not great

Bug #1582515 reported by Gustavo Niemeyer on 2016-05-17
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snapcraft
Wishlist
Sergio Schvezov
snapcraft (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned
Yakkety
Undecided
Unassigned

Bug Description

The "strip" phase name is not great. It's not actually stripping.. it's the phase that copies the content into the snap directory, as I understand it. So it's the opposite of stripping (although I understand where the motivation comes from). See how this command makes little sense, for example:

    snapcraft clean --step=strip

So it might be better named as something like "cast", or "shape", or "form". I'd check with Mark for the best word here.

[Impact]

 * One of the snapcraft commands is confusing.

 * The change is backwards compatible, so anything that's relying on strip will still work.

[Test Case]

 * Run snapcraft strip
 * Check that you get a deprecation message.
 * Clean
 * Run snapcraft prime
 * Check that the results are the same, without deprecation message.

[Regression Potential]

 * This could affect the strip command.

Gustavo Niemeyer (niemeyer) wrote :

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.

Gustavo Niemeyer (niemeyer) wrote :

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

Gustavo Niemeyer (niemeyer) wrote :

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.

Gustavo Niemeyer (niemeyer) wrote :

Ah, nice. So how about this:

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

Leo Arias (elopio) wrote :

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.

Gustavo Niemeyer (niemeyer) wrote :

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.

Sergio Schvezov (sergiusens) wrote :

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`

Gustavo Niemeyer (niemeyer) wrote :

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?

Mark Shuttleworth (sabdfl) wrote :

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

Sergio Schvezov (sergiusens) wrote :

Sure thing.

Changed in snapcraft:
importance: Undecided → Wishlist
milestone: none → 2.10
status: New → Triaged
assignee: nobody → Sergio Schvezov (sergiusens)
Sergio Schvezov (sergiusens) wrote :

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?

Sergio Schvezov (sergiusens) wrote :

Does `snap try prime` feel good?

Gustavo Niemeyer (niemeyer) wrote :

> 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. :)

Gustavo Niemeyer (niemeyer) wrote :

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.

Sergio Schvezov (sergiusens) wrote :
Changed in snapcraft:
status: Triaged → In Progress
Leo Arias (elopio) on 2016-06-02
description: updated
Changed in snapcraft:
status: In Progress → Fix Committed
Changed in snapcraft (Ubuntu Xenial):
milestone: none → xenial-updates
Launchpad Janitor (janitor) wrote :

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

Changed in snapcraft (Ubuntu Yakkety):
status: New → Fix Released

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!

Changed in snapcraft (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed
Changed in snapcraft:
status: Fix Committed → Fix Released
Leo Arias (elopio) wrote :

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!

tags: added: verification-done
removed: verification-needed
Kyle Fazzari (kyrofa) wrote :

> 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?

Leo Arias (elopio) wrote :

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.

tags: added: verification-failed
removed: verification-done
tags: added: verification-done
removed: verification-failed
Launchpad Janitor (janitor) wrote :

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

Changed in snapcraft (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers