Add Nix flake

[ramiuslr]

Hello again!

Here's a small proposal to add a flake declaration to make this code buildable in a Nix environment.
I've been using it without any issues in my home-manager config.

I'm not sure if you're interested in this since it's somewhat specific to one environment. I'm still learning NixOS, so I may not be fully experienced with it yet.
I'm also very unfamiliar about opening pull requests, so I hope I didn't forget anything.

Thanks !

[marevers]

Hi @ramiuslr , thank you for your contribution! This is a cool idea, I don't use NixOS myself but I do think it's nice to have some build documentation and having a second option besides just go build ... is nice as well.

Besides the mentioned change, could you maybe add a short 'Build' section to README.md to explain how to build with Nix? It does not need to be a complete how-to, but some hints are nice for potential other users. I will take care of adding some docs on how to build with the Golang environment so you don't need to worry about that.

Thanks so much for your contrib!

[marevers]

Is it possible here to get the version number externally, rather than configuring it directly in this file? The version number currently has its single source of truth inside of cmd/root.go.

pleasant-cli/cmd/root.go

Line 31 in 868b8b6

var version = "v0.8.1"

I see two options:

1. Retrieve the version number from that file.
2. Instead of storing the version number in that file, we add a separate VERSION file in the root of the repository which holds the version number. For the Go build process, I'll make a change that reads the version number from there instead of directly from the variable in cmd/root.go.

[ramiuslr]

Thank you for your great help !

I updated this pull request accordingly. I now use a Nix way to retrieve the version number from cmd/root.go. I also added some documentation to the README, I hope this will be clear and concise enough, otherwise I would be happy to improve it.

The only drawback I see is about updating the vendor hash when dependencies change, I added some information about that in the README.

I fact I think it depends the release model you have but I guess updating this hash before publishing a new version is not too much complicated. Otherwise I thought at a Github action but I'm not sure this is the optimal way to achieve updating this hash.

[ramiuslr]

Ooops looks like I messed up with my git history I'm sorry. If you prefer I can close this one a create a new clean PR...

[ramiuslr]

I looked at the commit history I don't know what happened but it rewrote the entire history so I'm gonna close this one and open a new clean PR, I'm so sorry 😅