As far as the particular examples of Eclipse and Gradle, I think the issue is that building java packages (especially big complicated ones like those) is currently rather painful in Nix. Unlike many other language ecosystems, we don't have a wealth of prepackaged libraries and dependencies for the JVM ecosystem, so unless you have a fairly small self-contained project, it's quite painful to build a new java project.
Of course we should improve that, but in the meantime we might as well package the jars. On Fri, Jan 8, 2016 at 8:26 AM, Eelco Dolstra <[email protected]> wrote: > Hi, > > On 08/01/16 11:26, Rok Garbas wrote: > > > Building from source is always possible. That's what Hydra.nixos.org > > <http://Hydra.nixos.org> > > does for you. The binaries from there are used iff the build > > instructions are exactly the same as what is available already. > > > > > > I think Juho (awesome name by the way!) was trying to figure out what > the is the > > general policy of nixpkgs expressions. > > > > I would say we are pragmatic there. We prefer to build from source and > use > > system libraries, but if this takes to much time to implement we are > also ok > > with reverting to building from binaries (or partially built binaries) > from > > upstream. > > I would state it a bit stronger: using binaries should only be done as a > last > resort. E.g. we use binaries for bootstrapping GHC because there really is > no > feasible way around that. But they should be avoided in general because > they > cannot really be audited or reproduced, let alone modified. > > -- > Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ > _______________________________________________ > 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
