The common way to do such things in nix is to write `fetchMaven` as
fixed-output derivation, documented here:
http://nixos.org/nix/manual/#fixed-output-drvs.
This requires you to specify the hash of the output of the derivation
upfront. You are then free to do anything you wish (including network
access) in the derivation, as long as the hash stays the same. Even if you
add additional build inputs etc I believe the hash shouldn't change, as you
manually specified it.
Regards,
Benno
Volth <vo...@volth.com> schrieb am Di., 9. Mai 2017 um 13:41 Uhr:
> There are already two versions in nixpkgs ("fetchMaven" and
> "fetchMavenArtifact") which are just wrappers for "fetchurl".
>
>
> Basicaly "fetchMaven" is merely a function giving argument
> "org.scala-lang:scala-compiler:2.11.11" produces a derivation by
> downloading two files
>
>
> https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.11.11/scala-compiler-2.11.11.pom
>
> https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.11.11/scala-compiler-2.11.11.jar
>
> into $out/share/java/.
>
>
> Besides the obvious hacky ways, how would it be possible to implement
> "fetchMaven" in a way that the output path in nixstore depend only on
> the argument ?
>
> Only on the string "org.scala-lang:scala-compiler:2.11.11" and not on
> curl version or buildScript's evolution (e.g. it could download PGP
> signature and validate it)
>
> Then the jar files would be easily discoverable by the external tools
> doing the same calculation.
> _______________________________________________
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
