It creates interoperability issues that can not be reconciled by
`lib` or maintainers of projects that use the Nixpkgs library.
Occasionally, end users may be able to solve the problems they run
into, but most are not prepared to deal with this set of problems,
nor should they be.
Typical conflict:
- User wants to propagate their own lib, because it has some function
they like to use throughout their projects
- Project maintainer requires the project's lib to be used
No sane language uses a single namespace for combining all the things.
(Arguably not even C with its extensive use of prefixing)
Meanwhile, in Nix, all symbols are first class variables. We don't even
have the concept of a global top-level namespace to pour everything into.
With `lib` you can try to approximate that, I get the appeal of its
apparent simplicity, but since `lib` can't be global, we just don't even
get that apparent simplicity.
I apologize for not offering concrete solutions to this in the text.
The manuals are limited to reference documentation.
Alternatives - of which we have multiple - are best provided in
task-oriented documentation, e.g. nix.dev.
It's not the longest-open PR (May 28, 2023 -> Jan 22, 2025) but it took a while. This PR introduces a unified approach to implementing build helpers that support fixed-point arguments and bring such support to existing build helpers.
Fix checkPhase by making it instalCheckPhase, since tcc depends on
libtcc1.a, which is build together with it, for its tests.
Create dev, doc and lib outpus. Now the binaries, i. e., tcc and the
cross compilers are what the user gets with tinycc.out.
Make the recipe compliant with nixpkgs-hammer.
Enable parallel building.
* doc/neovim: better document the wrappers
there is new wrapper interface `wrapNeovimUnstable` in development intended to be
easier to use than the old `wrapNeovim`. It provides new fancy features that we would like to
leverage/advertise
The interface is not definitive yet so we provide a translation layer
to avoid breaking user configurations such that `wrapNeovim` still works.
This explains why we document both at the moment with the goal to remove
the old one once we ciment the interface.
* doc/neovim: explain what buildNeovimPlugin does
reasoning:
- (doc -> code) make it easier to find where those are implemented
- to get easier insight if/what a specific renderer does with it
- in case one wants to improve them, which seems likely
as they are rather Nix/NixOS-specific
- (took me too long to find their implementation)
- (code -> doc) ensure changes to the code can be reflected in the doc
- code authors might not know about the reference documentation
or how to find it
I wanted to add instructions on how to configure neovim via the new
wrapper but it was difficult mixing this with both the vim and old
wrapper.
Neovim differs enough from vim to warrant its own section IMO:
1. its wrapper is different (old wrapper close to vim's syntax, new one
not so much)
2. treesitter is unique to neovim
3. the section about neovim plugins is unique to neovim as well. Not
only that but it needs to expanded.
At some point the doc unique to vim is going to exceed vim's.
We can refer to vim's section to avoid duplication where it makes sense.
Add flag pytestFlags as the new, conforming interface
replacing pytestFlagsArray.
Stop Bash-expanding disabledTests and disabledTestPaths.
Handle disabledTestPaths with `pytest --ignore-glob <path>`
to keep globbing support.
Check if each path glob matches at least one path
using the `glob` module from the Python standard library.
Also make buildPythonPackage and buildPythonApplication
stop escaping the elements of disabledTests and disabledTestPaths.
