[Nix-dev] Accessing files in derivations.

[Layus]

Adding attributes does not solve anything.
Package maintainers still have to take NixOS modules into account.
They have to provide workarounds if xxx.headers is not relevant anymore 
for example, and are responsible of cleaning up unused attributes.
This increases coupling between NixOS and "normal" nixpkgs packages.

But your description made me think of a viable workaround.
We could ensure that every derivation has a fixed set of known outputs, 
like dev, lib, out and man.
If there is no "lib" output, then the lib attribute could be an alias 
for out.

This is kind of a compromise.
NixOS modules can express their intent to access either executable, dev 
files or libraries, and packages maintainers can at will create or 
remove outputs.
It's not perfect because some files may not fit this scheme exactly, 
but, well... It would already help.

Regards,
-- Layus

On 19/04/16 19:00, Matthew Maurer wrote:
> Is there some reason we couldn't just encourage the exporting of paths 
> as package attributes? For example, say we currently have a package 
> libfoo, and it has some headers. Right now you might write:
>
> -I${libfoo}/include
>
> in some build command. We could however add an additional dictionary 
> of paths to libfoo, so that you would write:
>
> -I${libfoo.paths.headers}
>
> In the case that libfoo later created a "dev" split output package, 
> similar to debian's version of the same, the headers would migrate 
> outputs, and in the previous case you'd need to use
>
> -I${libfoo.dev-output}/include
>
> or similar, while the paths dictionary method would result in no need 
> for dependent packages to change anything.
>
> tl;dr I think moving the notion of which resources are available in 
> the package to the package itself might be a good way to refer to 
> logical resources - it makes it much more likely that the path exists 
> (since it was defined by the maintainer of the package, and as a 
> result is likely in sync), and is robust to package output splitting.
>
> --Matthew Maurer
>
> On Tue, Apr 19, 2016 at 12:51 PM, Vladimír Čunát <vcunat at gmail.com 
> <mailto:vcunat at gmail.com>> wrote:
>
>     On 04/19/2016 04:01 PM, Layus wrote:
>     > That operator would ensure that the path exists in the
>     derivation, but
>     > also look up through the outputs to find one containing that file.
>
>     Unfortunately, during evaluation you can't access the results of
>     builds
>     to check whether some path exists. (Well, technically you can, but we
>     avoid it, as it has nasty consequences.)
>
>     --Vladimir
>
>
>
>     _______________________________________________
>     nix-dev mailing list
>     nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
>     http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160419/dd85e936/attachment-0001.html