@peterhoeg I am sorry, I may had a strong wording and stupid position before *this. I still have old Nix models in my head sometimes. Creating a lib package - is just a split package output deal & I was thinking in other terms, while you probably was requesting just *this.

Since you were interested, maybe you would have other suggestions for package.

Sorry about the late reply, but I've had very little time for these last few weeks. Regd the multiple outputs, I believe it's considered best practise to have the out output as the last as a "catch all".

@peterhoeg I messaged above personally to you in the thread, because I needed to apologize.

Regarding outputs, I can say that I know no such thing as you say, my experience so far is the contrary.

I can inform you of this:

The manual states only this about out in split derivations:

Typically you also want to have the main out output, as it catches any files that didn't get elsewhere.

The only thing that really mentioned is that bin in most cases should be the first, as (AFAIK) binaries placed in first out. And binaries and bin itself - are default targets for binary path resolving.

The main and the only example that documentation gives for outs in split derivation is:

outputs = [ "bin" "dev" "out" "doc" ];

, which goes with the docs statement and not coincide with your consideration.

This all can be read in docs, at the start of the https://nixos.org/nixpkgs/manual/#sec-multiple-outputs- section.

So all things and my current experience point to that out is always a catch-all.

P.S.

If you have experience of the contrary is true, and would request for me to do this, and you know this as best practice and have such experience - I would kindly inquiry you back, as a person with such experience, to check availability of such best practice recommendations you know in the documentation and add such information into the documentation of Nixpkgs, because that would be the most practical and would save time for everyone. As it would be good if we all would be able to rely on the documentation.

Maybe as in the previous case, when I was thinking about the old Nix, maybe now here we have you remembering the old experience.

I am behaving here as a good contributor.
Because a bad contributor would not argue and just comply to the false statement so would stall the growth of the person (maintainer) by making him more sure that false is true. Also the bad contributor by not arguing would also help to perpetuate the growth of work, spreading and asking to do work for false statement, which would cause bugs to happen for some humans, and also would require a bug troubleshooting from someone, and if that person would be successful - require reporting from person, discussion about report and fixing back the false statements that people did and complied with.

You probably already seen such cases in Nixpkgs.

Also please remember that to the words of maintainer the contributor can not fight back, even to the statements of maintainer that are false. And any word of a maintainer, any, even false statements of a maintainer - require to be addressed by the contributor as true, and require work being gone by contributor and all things being checked by contributor, even false statements of a maintainer a good contributor should check if they are true. It is very easy to stall the process in any of such case, as maintainer can take the old Greek art of discussion with logical arguments personally, and contributor needs to be a real eloquent philosopher and diplomat to be able to build a real dialog to move things along.

So far as I checked the out is not required to be the last output, but of course, there is a possibility that I and documentation may not know something. I even reading the ./pkgs/build-support/setup-hooks/multiple-outputs.sh now, but as any relatively big shell code, even with good experience, it is hard to understand and reason about.

cc @FRidh who merges stuff into staging a bunch and probably knows about multiple outputs.

@Anton-Latukha is correct that there is no such practice of putting out last at the moment (it will be used a fallback output no matter the position). The only location that matters is the first output, which will be used as a default output when interpolating the package in a string. (e.g. "${djvulibre}/bin"), so the output containing primary executables should be first. Typically this is either out, or bin, if available, as you note.

Though, it is somewhat uncommon to have all of out, bin and lib. Usually a package is either primarily a library and then out is used instead of lib, or it is primarily a program and then out is used instead of bin. If there are all three, out will likely be almost empty. If this is intentional, it might be a good idea to add a comment explaining the outputs, see for example:

I marked this as stale due to inactivity. → More info