I think the idea is exciting but difficult. Some notes / questions:
1/ Nix stores its data in /nix/store - is your package manager OK with root
access? There are ways around that, e.g. using --with-store-dir but see [1].
2/ Do you want semver versioning or some form of always-follow-HEAD with
stabilization branches like e.g. nixos or stackage LTS do?
3/ Will you ever bind to c libraries like postgresql?
If you can fall back on binaries from your underlying system then maybe 1
isn't a problem - at the cost of reproducibility.
Personally I think I'd follow Domen's advice of machine readable metadata
and convert those into one big nix-expression on the fly before running
e.g. nix-build.
There are already several good examples for packaging *all* libraries for
an ecosystem from metadata (Peter's excellent Haskell work, Gleb's hex
packages, ...).
~
[1]
A while ago I spent some time trimming down nix to just stdenv.mkDerivation
+ lib + {git,svn,url} fetchers so I could use it as "import <nixpkgs-core>
{}". Rebuilding that with a different --with-store-dir still takes a long
time (using a path other than /nix/store disables binary substitution).
On 10 February 2016 at 05:48, stewart mackenzie <[email protected]> wrote:
> Rok! You're tickling me pink! Cheers!
>
> On 10 Feb 2016 04:52, "Rok Garbas" <[email protected]> wrote:
> > You could also create a wrapper around nix-build/nix-shell and generate
> part of
> > the derivation and feed it to standard buildFlowPackage function, right?
> Also
> > instead of generating you could also define a json format or any other
> format
> > but then you would have to implement a parser in nix yourself, but it is
> still
> > possible.
> >
> >
> > --
> > Rok Garbas - http://www.garbas.si
>
> _______________________________________________
> nix-dev mailing list
> [email protected]
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
_______________________________________________
nix-dev mailing list
[email protected]
http://lists.science.uu.nl/mailman/listinfo/nix-dev
