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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[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
