Comment 1 for bug 1737994

<sergiusens> cjwatson btw, mind if we work on switching snapcraft to use the snap for lp buidlers?
<cjwatson> sergiusens: I don't mind, but how were you planning to go about it?
<cjwatson> it's a bit involved
<sergiusens> cjwatson oh, then step one would be to get an idea of how involved it is :-)
<sergiusens> I had the impression it would be more about testing that s/apt install snapcraft/snap install snapcraft --classic/ was working as expected on staging
<cjwatson> sergiusens: we need to make it be a switch, not just change it in the code (which is harder to roll back, harder to experiment with on particular snaps, etc.); and probably as part of the same chunk of work we need to add channel control
<cjwatson> sergiusens: which means it needs to be propagated down from the LP buildd-manager, and probably needs data model changes
<sergiusens> cjwatson up to LP or even build.snapcraft.io ?
<sergiusens> I'll write up the proposed set of steps on the forum
<cjwatson> sergiusens: not build.snapcraft.io IMO. We can flip the switch eventually but it needs to be controlled
<cjwatson> sergiusens: IMO the steps are: (1) design data model in LP (possibly taking into account where core is installed from too, at least for the future?) (2) add option to snap build type in launchpad-buildd to cause it to install snapcraft as a snap (3) LP database migration to add whatever new columns we need (4) implement new data model and API changes in LP, and adjust the build args sent to builders (5) possible UI changes
<cjwatson> sergiusens: ordering is important because builders, DB migrations, LP code are all deployed independently so we need to ensure the right kind of compatibility