-
-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Package for Nixos #610
Comments
Happy to have a package, but no resources available to build one atm. Contributions welcome! |
I'm working on it :-). It may not be possible currently because the way dependencies are built into the project. Nixos likes to build from golang projects from source (it is a build system after all). It can handle go modules, with buildGoModule. There a few other 'nixos' tools to gather dependencies , mgmt seems to use a combination of 'go get' , 'go submodules', which may make it a little more difficult to get it compile in a nix enviroment. I may need to pick your brains on this build process (but not much). The main goal is to get all the source dependencies into the source tree before nix builds them, as once the build has start no network access is allowed (to help with a deterministic build :-) ). dep2nix converts a Gopkgs.lock file into a deps.nix file which is understood by nixpkgs's go abstraction thanks to go2nix effort. go2nix is best suited for Go apps written before dep or modules were introduced. vgo2nix Convert go.mod files to nixpkgs buildGoPackage compatible deps.nix files. It's a matter of unpicking you build system, and see if any of these can help. I'll have a hack to see where i can get. nixos declarative configuration + mgmt config, might be an interesting combination. |
If this would make your life easier (and ours too perhaps) We like building everything from git master to keep things fresh for now, but for packaging it's an issue. So I wanted to extend (via shell script I suppose) a "tag" script that saves a lock file with the currently used dep versions. So that it can be restored if you want to build a specific tag. You can use the standard golang module lock files if you'd like, they just need to get committed and stored in a subdir and not the root. If you can contribute that, it would be appreciated! I think it would then make building your nix package much easier. Ping if you'd like more details. |
Ping!!! :-). Well if there is a coherent way to make the build more 'nix' friendly, then it's worth exploring. If it builds in nix/nixos, then would you be willing to add a default.nix and shell.nix (and maybe even a flake.nix) to the root of the project?? Nix is a bit alien when you first see it but....as they say in The Hitch Hikers Guide to the Galaxy... DON'T PANIC!. as example, ipfs is buildable with the following nix expression. it builds https://github.com/ipfs/go-ipfs/tree/v0.6.0 can this project be laid out like this and avoid the 'make deps' stage all together? I'll working on fixing up the scripts and see if can get a compile with 'nix-shell -p go git' go version go1.14.8 linux/amd64 (is 1.14.8 too new) |
Not allergic to it AFAICT. I don't know enough about nix. If the files need to be in the root for nix to work, then it's probably okay. Otherwise they can go in misc/ happily.
How do you avoid it? Are you still going to work on the pinning of modules thing?
Probably not. Just bumped some deps to 1.13 as well. Tests also run on 1.14 -- We'll see if I missed anything shortly. |
Yes, I'm going to look at pinning etc when i get my head around the build process. nix likes shell script files to shebang to be portable friendly. https://www.cyberciti.biz/tips/finding-bash-perl-python-portably-using-env.html so changing #!/bin/bash to #!/usr/bin/env bash some projects refuse to do this, if your not adverse to it , i can make a PR. Also, would you say setting CGO_ENABLE=0 (to output a static binary) a problematic thing with mgmt. |
I'll make you a deal... Once the go pinning stuff is merged, I'll accept or write the patch to switch this stuff for you if you like.
Is this what you want? Line 159 in 76ede10
|
again, it's just nix weirdness, where golang is trying to install a library into a the readonly /nix/store Building: mgmt, os/arch: linux-amd64, version: 0.0.21-92-ge99dd74-dirty... make: *** [Makefile:175: build/mgmt-linux-amd64] Error 1 setting CGO_ENABLED=0 seems to clear that up for now... Stuff like this is probably why developers run a mile from nix when they first see it, then run back when they realise how handy it is. There seems to be a number of weird and wonderful ways to do dependency management with golang, and i'm just trying to see what approach works well with nix. Doing a build on ubunutu bionic maybe at least look what a sane build looks like. I may accept this deal ... however. https://www.youtube.com/watch?v=WpE_xMRiCLE ;-) |
We can always add a new build target for nix if needed. But maybe try setting GOPATH to something totally writable and see if that helps.
For your patch it should probably be a bit of bash combined with the new standard go modules.
I'm not wearing your clown shoes. |
Ok, I have mgmt compiling and runnng on Nixos within a Nixshell. This is the first step to getting a full nixos package done. I had to do the following things. patch the shebang !#/bin/bash to a portable #!/usr/bin/env bash to avoid
I had to remove the -i from
this seems to be related to this and upstream here
to run
|
FYI I've started work on a nix derivation using the
Some patches were needed to improve dependency handling via
Next issue is figuring out how to dynamically create the [1] https://github.com/purpleidea/mgmt/blob/master/lang/funcs/Makefile |
OK, after a bunch of wranling I came up with this
Haven't tested further than a $ mgmt --help
NAME:
mgmt - next generation config management
USAGE:
mgmt [global options] command [command options] [arguments...]
VERSION:
0.0.22-41-g7e90b0d
COMMANDS:
run, r Run code on this machine
deploy, d Deploy code into the cluster
get, g Download code from the internet
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--license prints the software license (default: false)
--help, -h show help (default: false)
--version, -v print the version (default: false) but we're off to a start... Next steps
|
@dantefromhell I'd like to apologize for not replying earlier. I haven't been receiving github notifications. It's a bug they had once with my mailserver but it is apparently back. If there's anything I'm blocking, please lmk and I can patch in mgmt. Cheers |
@purpleidea I believe I got some possible upstream changes related to #693 worked out in the process of creating the NixOS build, but also broke some of the automated testing along the way [1]. I still need into fixing those tests (might have done some other breaking changes in my fork too). In case any of this is useful for you, please re-use as it makes sense. And once I have capacity to fix the testing you can check what of the changes make sense upstream. |
I'm super busy with my startup right now, but i still got a place for mgmt-config in my heart! |
@dantefromhell I quite recentl updated a bunch of go mod stuff so everything builds again. This is coincidentally around the exact same time you made your comment AFAICT. LMK if rebasing to latest master helps, and anything else, please let me know and I'll patch or merge. |
hope I am not stepping on your toes @dantefromhell with my pr, but thank you for your inspiration! I built mine from the ground up, so there are a few things missing from your latest version, thus please feel free to test, contribute, or give feedback, as I did not do much more than get it to compile and run a few basic commands to ensure it actually did compile. @purpleidea, any chance we can get a release tagged, so that we can have a real version like |
@urandom2 |
@urandom2 You're saying getting a newly tagged release would be helpful to the nix folks? Please confirm, and then sure, I can do that. Is there anything else in the diff for packaging that we can merge upstream here to make this easier? Do you want to push the packaging stuff upstream here? Cheers |
@urandom2 |
nixpkgs does not need a new release, I just prefer to package against releases, since the version strings look better and it guarantees that we are not going to ship wip features. that said, I have done this in NixOS/nixpkgs#198963 because 0.0.21 is so far out of date that i could not trivially get it to build. end of the day, you should release on the cadence you are comfortable with, but yeah a new tagged release would be awesome!
generally nix is a special case, so I do not want you to bend over backwards to support us. go as a toolchain, very much requires authors to check in generated code (if you want
a |
Propose anything that you think makes sense. If I don't think it's a good for mgmt I won't merge it.
Unfortunately we do a good deal of code generation, and I realize this makes a few things harder. Maybe we'll switch away from this in the future. But
I have no idea what this is, but patches welcome! |
Send patches for this if you want. Also -i stuff I think it's deprecated now. HTH |
yep, and no shame about code generation; the standard library does plenty and they use go generate too; the difference with mgmt is you I will submit what I am thinking about as a pr, and validate that
there is something on the way, so I will open it up when I can manage to get it building. |
I understood, and while it is a good idea, I still don't love the idea of committing generated code when there isn't a major win. |
Nixos and Mgmt Config might be combination for the following reasons (there are many more).
https://nixos.org/
Keeping secrets out of the /nix/store
Coordinating and running changes to /etc/nixos/configuraton.nix (and import files). (on a git commit)
Setting up tests infrastructure
Integrating with Nixops
The text was updated successfully, but these errors were encountered: