Context:
@FlafyDev: I think flutter apps in nixpkgs should be required to specify
a flutter version. like flutter319 and flutter322 instead of using
flutter.
https://github.com/NixOS/nixpkgs/pull/313711
This makes `justStaticExecutables` error if the produced store path
contains references to GHC. This is almost always erroneous and due to
the generated `Paths_*` module being imported. This helps prevent
`justStaticExecutables` from producing binaries with closure sizes in
the gigabytes.
See: https://github.com/NixOS/nixpkgs/issues/164630
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
* doc: autogenerate python interpreter table
This serves as a practical example on generating documentation by
inspection of the evaluated Nixpkgs tree.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
This change fixes cross-compilation for .NET packages (that are not
using .sln as project files). See relevant comment in the change list
for more details.
In addition to that, it removes dotnet-test-sdk that appears to be
broken, that is, dotnet --list-sdks does not recognize SDKs from PATH,
and when propagated from the check hook it was shadowed by inputs from
preceding hooks.
Note that dotnet-test-sdk used to work when it was introduced in PR
144062, but PR 155257 probably overlooked this case. However, currently
it is not used in Nixpkgs and I think dotnetCorePackages.combinePackages
should cover the intended use case for dotnet-test-sdk.
Fixes#256769
Repro + test of fix here: https://gitlab.com/ramirez7/bug-repros/-/merge_requests/1
Adds a `srcModifier` argument to `callCabal2nixWithOptions` to allow
customizing the source files used to generate the cabal file (e.g. to
support `hpack`/`package.yaml`).
In the past I was very active with Python packaging.
For several years now I was hardly around as maintainer,
so it does not make sense I am listed as a maintainer for
these makes. Looking back, I should have removed myself
as maintainer already much longer ago. Anyway, better late
than never.
It's been a fun ride, and I do intend to occasionally contribute
to Nixpkgs, but not in the same way it once was.
This was achieved using the following command:
sd 'wrapGAppsHook\b' wrapGAppsHook3 (rg -l 'wrapGAppsHook\b')
And then manually reverted the following changes:
- alias in top-level.nix
- function name in wrap-gapps-hook.sh
- comment in postFixup of at-spi2-core
- comment in gtk4
- comment in preFixup of 1password-gui/linux.nix
- comment in postFixup of qgis/unwrapped-ltr.nix and qgis/unwrapped.nix
- comment in postFixup of telegram-desktop
- comment in postFixup of fwupd
- buildCommand of mongodb-compass
- postFixup of xflux-gui
- comment in a patch in kdePackages.kde-gtk-config and plasma5Packages.kde-gtk-config
- description of programs.sway.wrapperFeatures.gtk NixOS option (manual rebuild)
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.
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!
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).
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.
`lib.recursiveUpdate` indiscriminately recurses into all attribute sets,
also into derivations. This means that it is possible that evaluating a
derivation in the final haskell package set can cause something in
`prev.haskell` to be forced by `recursiveUpdate`, potentially causing an
evaluation error that should not happen.
It can be fixed using a well-crafted predicate for
`lib.recursiveUpdateUntil`, but most robust is just explicitly writing
out the desired merging manually.
lualatex assumes a writeable font cache relative to `$HOME`, for nix this has two implications.
First, the cache might diverge from the nix store if users use LuaLaTeX.
Second, `$HOME` needs to be set to a writable path in derivations.
It is fine to use `with` on the inputs, since that increases the
overall readability of the package.
Removes `wheel` from `nativeBuildInputs`, since it is a result of
cargo culting from an earlier setuptools example, that was wrong, and
it is not required, since it is provided by setuptools itself.
The python-updates branch was formerly called python-unstable, but the
new branch name was never mentioned in the docs. This commit changes the
branch name in the docs to python-updates.
We get a dependency list with pub2nix now. We can no longer easily distinguish between development dependency dependencies and regular dependency dependencies, but we weren't doing this anyway.
Fixes some mistakes regarding the references to cargoHash in the codes referenced.
Fixes a typo for cargoSha256.
States that cargoHash should be preferred.
Without this, it's impossible to override the lockFile as the default
overrideAttrs is applied after the composition in buildNimPackage has
read the lock file and generated the nim flags from it.
We keep running into situations where we can't get the right
combination of rustc flags through build systems into rustc.
RUSTFLAGS is the only variable supported across build systems, but if
RUSTFLAGS is set, Cargo will ignore all other ways of specifying rustc
flags, including the target-specific ones, which we need to make
dynamic musl builds work. (This is why pkgsCross.musl64.crosvm is
currently broken — it works if you unset separateDebugInfo, which
causes RUSTFLAGS not to be set.)
So, we need to do the same thing we do for C and C++ compilers, and
add a compiler wrapper so we can inject the flags we need, regardless
of the build system.
Currently the wrapper only supports a single mechanism for injecting
flags — the NIX_RUSTFLAGS environment variable. As time goes on,
we'll probably want to add additional features, like target-specific
environment variables.
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
