Minor improvements to Nix expresions

[domenkozar]

See commits for summary.

@eugeneia should we document somewhere that .version needs to be bumped on each release?

cc @kbara

[eugeneia]

Is there any way we could avoid the .version file? The way I see it it will be wrong/misleading in most commits and this information is already encoded in git tags.

[domenkozar]

I'm open for suggestions, but in Nix we can't depend on .git since nix hash
is content addressed and .git folder is not deterministic for a given git
commit rev.
On Jun 13, 2016 12:12 PM, "Max Rottenkolber" notifications@github.com
wrote:

Is there any way we could avoid the .version file? The way I see it it
will be wrong/misleading in most commits and this information is already
encoded in git tags.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#939 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAHtg5P-qNPl_LR_-dEz7FtZo51m_jj_ks5qLTr0gaJpZM4Iy5jB
.

[lukego]

How about if release.nix would take the software version, etc, as parameters? i.e. instead of being a completely stand-alone release-and-test procedure it would simply be nix library code that can be referenced from other repositories e.g. nixpkgs and snabblab-nixos.

I see a few issues with trying to bake everything into the snabb/release.nix file:

1. Determining software version, as we already discuss.
2. Snabb has a distributed development workflow, where independent groups can make their own releases from their own application-specific branches, and it will be conflict-prone if everybody is changing the .version on their branch and then merging with each other.
3. The release.nix is also referencing infrastructure like lugano server hardware which seems to me logically a part of the Snabb Lab (i.e. snabblab-nixos repo) and not of the software itself (which may be built/tested/released in a completely different environment e.g. upstream nixpkgs).

[domenkozar]

I agree we should make release.nix more like a flat list of helper functions and disregard snabblab information.

.version could denote "upstream version" on which Snabb fork is based. I realize it's extra work for releases, we could name development branch 2016.07.dev or something similar.

It's possible to avoid this in Nix, but for every git checkout I need to explicitly specify the version. Not the end of the world, but also quite tedious.

That being said, I'll accept if we remove .version with "too much of a burden" reasoning.

[kbara]

I'd like to see consensus about what to do about version handling before merging this.

[domenkozar]

@kbara we decided not to hardcode due to the forking workflow, which would be very confusing for downstream. Instead, we'll just provide the version manually based from where Snabb will be imported.

Ready for review :)

[domenkozar]

Aha - this fails due to problems with davos/CI.

[domenkozar]

@kbara snabb-nfv-test-vanilla passes, so this is ready to be merged.

[kbara]

LGTM, thanks for this. Merged into kbara-next, PR'd for next.