I do have a couple of conclusions after reading through most of lib/:

1. lib.or was mostly a mistake. Having a token that's part of the Nix grammar also be an identifier is really ambiguous. lib.and has the same problem.
2. Having an explicit list of symbols to export definitely reduces the chance of exporting a helper function that isn't used outside of lib. For instance, lib.systems.parse exports gnuNetBSDDefaultExecFormat, and I bet it didn't mean to.
3. let ... in blocks are great.
4. Whether to use lib or builtins is made substantially harder by lib not being a drop-in for builtins.

Philip Taron (UTC-8):

1. Oh damn didn't realise that, though I never used or nor do I see a good use case for it. I think lib.and should be fine, since there's no and keyword
2. +1
3. +1
4. Yeah.. I think this should be fixed, though I guess some builtins might not make sense in lib, like builtins.import or builtins.fetchGit (or does it?)

In reply to @infinisil:matrix.org
Philip Taron (UTC-8): That's && :P

I do have a couple of conclusions after reading through most of lib/:

1. lib.or was mostly a mistake. Having a token that's part of the Nix grammar also be an identifier is really ambiguous. ~lib.and has the same problem.~
2. Having an explicit list of symbols to export definitely reduces the chance of exporting a helper function that isn't used outside of lib. For instance, lib.systems.parse exports gnuNetBSDDefaultExecFormat, and I bet it didn't mean to.
3. let ... in blocks are great.
4. Whether to use lib or builtins is made substantially harder by lib not being a drop-in for builtins.

I do have a couple of conclusions after reading through most of lib/:

1. lib.or was mostly a mistake. Having a token that's part of the Nix grammar also be an identifier is really ambiguous. lib.and has the same problem.
2. Having an explicit list of symbols to export definitely reduces the chance of exporting a helper function that isn't used outside of lib. For instance, lib.systems.parse exports gnuNetBSDDefaultExecFormat, and I bet it didn't mean to.
3. let ... in blocks are great.
4. Whether to use lib or builtins is made substantially harder by lib not being a drop-in for builtins.

In reply to @philiptaron:matrix.org
Since I opened the PR, I've formed a small bias towards the shortest path. So if a name is re-exported from lib, I'll use that.

@ma27: figuring out which submodule to pull from -- and keeping them straight -- is one reason I end up favoring inherit (lib) name. Even with the with lib;, you still needed to know what name was, so the answer is pretty straightforward, I think:

1. Put inherit (lib) name at the same place you'd land with lib;
2. Use name normally.

In reply to @philiptaron:matrix.org
Since I opened the PR, I've formed a small bias towards the shortest path. So if a name is re-exported from lib, I'll use that.

ma27: figuring out which submodule to pull from -- and keeping them straight -- is one reason I end up favoring inherit (lib) name. Even with the with lib;, you still needed to know what name was, so the answer is pretty straightforward, I think:

1. Put inherit (lib) name at the same place you'd land with lib;
2. Use name normally.

In reply to @philiptaron:matrix.org
On lib.or: as far as I can tell, it's used in three files (lib/options.nix, pkgs/build-support/writers/data.nix, and pkgs/build-support/writers/scripts.nix) and for the uses in writers it could be trivially replaced with ||.