Broken since the switch to PyPA's build/installer in
6c85fff302.
The hook was always janky and maintainers appear to not want its current
implementation in-tree. No replacement is currently planned.
However, this leaves the path open for future replacements as a broken
hook will no longer be installed by default.
Cython is a Python compiler that emits native .so modules. By default, python derivations run tests in the wrong directory to see these modules and tests fail.
Issue #255262 documents the root cause and solution for this problem.
This PR adds a description of the problem and the most common solution to the test troubleshooting list.
Replace writeReferencesToFile with writeClosure.
Make writeClosure accept a list of paths instead of a path.
Re-implement with JSON-based exportReferencesGraph interface provided by
__structuredAttrs = true.
Reword the documentation.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Someone Serge <sergei.kozlukov@aalto.fi>
* doc: fix and simplify stylesheets for the manuals, fix nrd bug
* Add anchorjs script to add links on section headers
* Fix another nrd bug, address style changes
* Use span instead of a for inline span syntax
This PR refactor CUDA setup hooks, and in particular
autoAddOpenGLRunpath and autoAddCudaCompatRunpathHook, that were using a
lot of code in common (in fact, I introduced the latter by copy pasting
most of the bash script of the former). This is not satisfying for
maintenance, as a recent patch showed, because we need to duplicate
changes to both hooks.
This commit abstract the common part in a single shell script that
applies a generic patch action to every elf file in the output. For
autoAddOpenGLRunpath the action is just addOpenGLRunpath (now
addDriverRunpath), and is few line function for
autoAddCudaCompatRunpathHook.
Doing so, we also takes the occasion to use the newer addDriverRunpath
instead of the previous addOpenGLRunpath, and rename the CUDA hook to
reflect that as well.
Co-Authored-By: Connor Baker <connor.baker@tweag.io>
Following [Best Practices](https://nix.dev/guides/best-practices#with-scopes),
`with` is a problematic language construction and should be avoided.
Usually it is employed like a "factorization": `[ X.A X.B X.C X.D ]` is written
`with X; [ A B C D ]`.
However, as shown in the link above, the syntatical rules of `with` are not so
intuitive, and this "distributive rule" is very selective, in the sense that
`with X; [ A B C D ]` is not equivalent to `[ X.A X.B X.C X.D ]`.
However, this factorization is still useful to "squeeze" some code, especially
in lists like `meta.maintainers`.
On the other hand, it becomes less justifiable in bigger scopes. This is
especially true in cases like `with lib;` in the top of expression and in sets
like `meta = with lib; { . . . }`.
That being said, this patch removes most of example code in the current
documentation.
The exceptions are, for now
- doc/functions/generators.section.md
- doc/languages-frameworks/coq.section.md
because, well, they are way more complicated, and I couldn't parse them
mentally - yet another reason why `with` should be avoided!
`snapTools.makeSnap` has produced broken snaps since at least Oct 2020,
as indicated by the following issue: https://github.com/NixOS/nixpkgs/issues/100618
No person has shown interest in maintaining it, and given that there is
no fix available, it's assumed that all attempts made to fix that
function have not succeeded.
Given that `snapTools` only contained `makeSnap`, it was removed
completely.
This is an alternative to `fetchNpmDeps` that is notably different in that it uses metadata from `package.json` & `package-lock.json` instead of specifying a fixed-output hash.
Notable features:
- IFD free.
- Only fetches a node dependency once. No massive FODs.
- Support for URL, Git and path dependencies.
- Uses most of the existing `npmHooks`
`importNpmLock` can be used _only_ in the cases where we need to check in a `package-lock.json` in the tree.
Currently this means that we have 13 packages that would be candidates to use this function, though I expect most usage to be in private repositories.
This is upstreaming the builder portion of https://github.com/adisbladis/buildNodeModules into nixpkgs (different naming but the code is the same).
I will archive this repository and consider nixpkgs the new upstream once it's been merged.
For more explanations and rationale see https://discourse.nixos.org/t/buildnodemodules-the-dumbest-node-to-nix-packaging-tool-yet/35733
Example usage:
``` nix
stdenv.mkDerivation {
pname = "my-nodejs-app";
version = "0.1.0";
src = ./.;
nativeBuildInputs = [
importNpmLock.hooks.npmConfigHook
nodejs
nodejs.passthru.python # for node-gyp
npmHooks.npmBuildHook
npmHooks.npmInstallHook
];
npmDeps = buildNodeModules.fetchNodeModules {
npmRoot = ./.;
};
}
```
I was looking at
https://nixos.org/manual/nixpkgs/stable/#buildpythonpackage-parameters to
import a Python package and noticed that the link for the `hooks` in
`pyproject` option is broken due to a typo (used <kbd>0</kbd> instead of
<kbd>)</kbd>).
Signed-off-by: Mihai Maruseac <mihai.maruseac@gmail.com>
Much like the previous commit that adds dependencies &
optional-dependencies this aligns PEP-517 build systems with how they
are defined in PEP-518/PEP-621.
The naming `build-system` (singular) is aligned with upstream Python standards.
Since https://github.com/NixOS/nixpkgs/pull/161835 we've had the
concept of `passthru.optional-dependencies` for Python optional deps.
Having to explicitly put optional-dependencies in the passthru attrset
is a bit strange API-wise, even though it semantically makes sense.
This change unifies the handling of non-optional & optional Python
dependencies using the names established from PEP-621 (standardized pyproject.toml project metadata).
This commit adds support for swapping out the compression algorithm
used in all major docker-tools commands that generate images. The
default algorithm remains unchanged (gzip).
There is an arbitrary mapping being done right now between
nixpkgs lua infrastructre and luarocks config schema.
This is confusing if you use lua so let's make it possible to use the
lua names in the nixpkgs, thanks to the lib.generators.toLua convertor.
The only nixpkgs thing to remember should be to put the config into `luarocksConfig`
`buildLuarocksPackage.extraVariables` should become `buildLuarocksPackage.luarocksConfig.variables`
I believe it would be helpful to better explain how to use
`nuget-to-nix` for those who aren't familar with the .NET ecosystem as I
was personally stumped on how to use it.
