Skip to content
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

Add goDeps handling to go-modules. #94585

Closed
wants to merge 2 commits into from
Closed

Add goDeps handling to go-modules. #94585

wants to merge 2 commits into from

Conversation

c00w
Copy link
Contributor

@c00w c00w commented Aug 3, 2020

As far as I can tell this works, but it appears the no goPackage has a valid deps file that works with go modules. I'm mostly putting this up so people can see how it works. I think the next step is a tool which correctly generate a deps.nix based on module information. (likely I'll add it to govendor form nix-community)

Motivation for this change
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@c00w
Copy link
Contributor Author

c00w commented Aug 3, 2020

cc @Mic92 @kalbasit

@doronbehar
Copy link
Contributor

CI error.

mkdir source
${depCommand}
${proxyCommand} &
export "GOPROXY=http://localhost:8080"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will cause trouble if no sandbox is used because 8080 will be bound twice.

Comment on lines +59 to +79
dep2src = goDep:
{
inherit (goDep) goPackagePath;
src = if goDep.fetch.type == "git" then
fetchgit {
inherit (goDep.fetch) url rev sha256;
}
else if goDep.fetch.type == "hg" then
fetchhg {
inherit (goDep.fetch) url rev sha256;
}
else if goDep.fetch.type == "bzr" then
fetchbzr {
inherit (goDep.fetch) url rev sha256;
}
else if goDep.fetch.type == "FromGitHub" then
fetchFromGitHub {
inherit (goDep.fetch) owner repo rev sha256;
}
else abort "Unrecognized package fetch type: ${goDep.fetch.type}";
};
Copy link
Member

@Mic92 Mic92 Aug 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering we could not just accept file that is called with callPackage.
The file would have all required fetchers in its header:

{ fetchgit, fetchhg }: {
   "github.com/foo" = fetchgit { ... };
   "somehost.com/foo" = fetchhg {};
}

Advantage is better extensibility. And we could replace/patch dependencies by its go path.
The patching could be even done with a global override file so it does not need to be done per package.

If we want to apply patches it might be with a global override file it might be beneficial to also have the version number/revision.

{ fetchgit, fetchhg }: [
   { path = "github.com/foo"; src = fetchgit { ... }; version = "1.0.0"; };
]

We could not just apply patches but also add extra build dependencies like pkg-config or c libraries in a globally maintained override file:

{ sqlite, pkg-config }: {
   "github.com/foo" = { version }: {
      patches = lib.optional (lib.versionOlder version "0.9") []; 
      buildInputs = [ sqlite ];  
      nativeBuildInputs = [ pkg-config ];
   };
}

This is similar to https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/ruby-modules/gem-config/default.nix#L63

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants