Change:
ioport = callPackage ../os-specific/linux/ioport {}; <ins> dgoss = callPackage ../tools/misc/dgoss { }; </ins> diagrams-builder = callPackage ../tools/graphics/diagrams-builder { inherit (haskellPackages) ghcWithPackages diagrams-builder; };

Discussion:
Project description This is a follow-up to issue goss. is a bash script wrapper for . It helps install and run inside docker containers and together with it's very handy to run continuous integration tests when building docker images. For example it lets you build a docker image, run a container with it and validate that the image works as expected, that files have the right permission / mode, that some port is open, that some command gives the expected result, etc. is maintained and released from the same Github repo as . I have tried packaging it but since it's a bash script and it's only my second contribution to nixpkgs, I'm having a hard time. I've tried using to replace references to commands, such as , and so on. relies on a environment variable and falls back on to locate the binary. I imagine in nixpkgs we could replace this line and "hardcode" as a dependency of . However, I was not able to do so. I need your help :sweatsmile: :pray: Here is my attempt so far: Metadata homepage URL: source URL: license: Apache License 2.0 () platforms: From the README it looks like it's linux and Darwin
In the long run resholve may directly patch things like but for now the best way to handle the GOSSPATH with resholve would probably be supplying a "prologue" that sets GOSSPATH. (resholve has options for passing a prologue or epilogue--paths to a file to prepend or append--but it doesn't look like I've documented or given examples outside of the test-suite; you can use it by supplying a attr to the solution.) As an aside, I wondered a bit about this being a separate package from goss. I peeked a few place in the goss source and without reading very deeply it looks like some places/instructions will install both while others treat it as optional? Are you separating them for some reason directly related to goss/nixpkgs, or just to work around the awkwardness of resholve's package-oriented nix API?
Hi, thanks for the help, I'll try that out :) About the package being separate from goss, honestly I don't know :sweat_smile:.

It wasn't to work around resholve's nix API, I just figured that since it was a separate binary, it had to be a separate package in nixpkgs.
I've made , functions but there seems to be a problem with now. will mount the binary in the docker container and runs commands on it. I don't really understand the "not found" error but I've read that it can happen when a program is dynamically linked and does not find one of its dependencies
I needed to fix the packaging (which was building the dynamically linked binary). works, thanks for the help I'll wait for the PR to be merged before pushing one for
Can you bring up the question about whether dgoss should be separate or not in the other report? I'm not sure what the razor should be. One thought is to track whatever the other repos are doing. Per it looks like they both include dgoss, but one also includes kgoss and dcgoss.
:ok_hand:
goss is commonly used on its own in containers and other environments where you'd want minimal dependencies so I'm more inclined to package them separately rather than have people use overlays on goss to remove them