Add the packaging metadata to build the solidity snap

[come-maiz]

This is a package for the secure installation of apps that works in most Linux distributions.
Landing it upstream will enable builds that then can be distributed to many users through the Ubuntu store.

[come-maiz]

Hello!

I've been learning a little about solidity this days. Just as with cpp-ethereum, this would be a great addition to the Ubuntu store. From there you will make your software and the updates easily available to millions of users.

The parity team, for example, is already getting testers from the community that are using their snap on the edge channel, and can provide useful early feedback while preparing the next stable release.

As usual, you can give this a try in an Ubuntu 16.04 machine with:

$ sudo apt install git snapcraft
$ git clone https://github.com/elopio/solidity
$ cd solidity
$ git checkout snapcraft
$ snapcraft
$ sudo snap install *.snap --dangerous

[chriseth]

Thanks for your contribution! At the current stage, we cannot maintain such package formats. Would you be volunteering for maintaining it?

[come-maiz]

@chriseth I would love to! I can even set up the continuous delivery on launchpad, so you don't need to give me access to the solidity repo.
Should I register the solidity name in the store under my account, or would you like to make an account for your team and make me a collaborator there? This is done in https://dashboard.snapcraft.io/

[come-maiz]

Ping @chriseth. I have everything ready for the continuous delivery here: https://launchpad.net/solidity
I'm just missing this branch to land, so launchpad can take the snapcraft.yaml. And for now, I can register the package in the store under my name, and transfer it later to you if you want to keep the delivery under upstream control.

pura vida.

[chriseth]

Sorry for being unresponsive. I think we had a discussion about a similar topic already: Does snap require the "snap" directory, or can we just use a more generic directory and put the snapfile there? The "scripts" directory is not too fitting from its name, but at least all the packaging scripts are there. So is it possible to put it in scripts/snap/snapcraft.yaml?

[come-maiz]

The continuous delivery in build.snapcraft.io and launchpad.net assume that the file is in {root}/snapcraft.yaml, or in {root}/snap/snapcraft.yaml. We can put it anywhere else, but we would have to use travis or something like that for CD, which is a little more work.

So doable, of course, just not as comfortable. It's your repo, so your decision. Let me know if I should move it.

[chriseth]

ok, thanks!

forgot something...

[chriseth]

Ah, one more thing: How does snap handle the versioning? I'm asking because we have a special mechanism that creates a different version string (reported in solc --version' but also in packages) when the commit is an actual release (identified by a tag starting with the letter v`).

[come-maiz]

@chriseth if you use annotated tags, then the version could just be version: git, and when we are building a snap from a commit with a tag, it will take the version of the tag. You are not using annotated tags at the moment, which is a good practice IMO. May I suggest you to start using them?

If you want to continue with lightweight tags, then we can use the keyword version-script to run a script that will return the same value that solc --version returns.

I'm not worrying about that right now because the continuous delivery will just take the latest master and put it in the edge channel. So to start the testing, actually using master as the version makes sense. When we are ready to start moving tagged versions to the candidate and stable channels, I will come back and adjust the yaml to be smarter.

[chriseth]

This is not just about tags, it is about what solc --version reports and about the version it stores in the generated bytecode. Basically the requirement would be to create an empty file called prerelease.txt in the root directory whenever the package is built for a tagged commit. But yeah, let me merge this and then we can see how it goes.

Oh and by the way: We do not use the master branch, only the branches develop and release.

[come-maiz]

@chriseth ah, I see what you mean.

This is the output from the snap built from develop:

$ solc --version
solc, the solidity compiler commandline interface
Version: 0.4.13-develop.2017.7.6+commit.eca2655c.Linux.g++

This is the output from the one built from the 0.4.12 tag:

$ solc --version
solc, the solidity compiler commandline interface
Version: 0.4.12-develop.2017.7.6+commit.194ff033.Linux.g++

This is going to be interesting. I have a few ideas of how to do it, but I have to experiment a little.

Thanks for bringing it to my attention.

[chriseth]

Right, the 0.4.12 tag should actually report 0.4.12+commit.194ff033.Linux.g++.