In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
* luarocks-packages-updater: convert into pyproject package
* pluginupdate: move to its own folder
so we can copy just the folder when using this as a module
* luarocks-packages-updater: adress review
I made this, and I almost completely deleted it because I was fully
on board with lz-n again. However, I have been using it and lz-n
simultaneosly and trying them out.
I wish to publish lze after all. I like it a lot.
It works completely differently from lz-n and has a different handler
api, but has a similar plugin spec.
Update pkgs/development/lua-modules/overrides.nix
Co-authored-by: Gaétan Lepage <33058747+GaetanLepage@users.noreply.github.com>
Everything gets moved into the `ci/` top-level directory.
We keep behind `maintainers/scripts/check-by-name.sh` and `pkgs/test/check-by-name/pinned-version.txt` as they are going to cause CI errors and confusion until we get all the way through the various channels.
They'll be removed in about a week or so.
With cabal-install >= 3.12, we need to adjust our cabal-install overlay
once again.
- Due to the new dependency semaphore-compat, which appears to require
unix >= 2.8 it is very difficult to get to work for GHC < 9.6 (but
probably possible). Technically, using pkgs.cabal-install should
always be fine, so there's no strict need for cabal-install to work
with every GHC. Let's drop support for GHC < 9.6 for now.
- Make sure that cabal-install-solver also uses the latest version
always.
- Due to Cabal 3.12, we need to deviate from Stackage for
hackage-security. cabal-install does support the standard version of
resolv now, though.
`nix develop .#vimPluginsUpdater` now lets you enter a shell where you
can run `pkgs/applications/editors/vim/plugins/update.py` and
iteratively develop !
- removed `warn` warning from python by using `warning` instead
- `plugin2nix` was calling the same bit of code over and over thus
slowing down the generator by a lot
The context manager would previously just terminate early on exception.
As a result, the worktree and branch would not get pruned when update script failed.
Let’s wrap the cleanup code in `finally` block as suggested by Python docs:
https://docs.python.org/3/library/contextlib.html#contextlib.contextmanager
