jiebi/CodeConvo huggingface dataset:
Code change:
Project description Floorp is a firefox fork. Metadata homepage URL: source URL: license: MPLv2.0 platforms: windows, macos, linux

Related discussion:
text: flex-ndax = callPackage ../applications/radio/flex-ndax { }; <ins> floorp-unwrapped = callPackage ../applications/networking/browsers/floorp { }; floorp = wrapFirefox floorp-unwrapped { }; </ins> fluxbox = callPackage ../applications/window-managers/fluxbox { }; hackedbox = callPackage ../applications/window-managers/hackedbox { };
Code change:
Project description A wayland native, highly customizable runner. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: gpl3 platforms: linux
NB: they have a flake
You have to compile it if you add the flake and the Cachix currently doesn't work. I rather it to nixpkgs because it way more dependent here.
I can work on getting it into nixpkgs shortly.
Oo nice :3 Thank you so much

Related discussion:
text: <ins> { lib , rustPlatform , fetchFromGitHub , pkg-config , wrapGAppsHook , atk , cairo , gdk-pixbuf , glib , gtk3 , pango , stdenv , darwin , wayland , gtk-layer-shell , unstableGitUpdater }: rustPlatform.buildRustPackage rec { pname = "anyrun"; version = "0-unstable-2023-12-01"; src = fetchFromGitHub { owner = "kirottu"; repo = "anyrun"; rev = "e14da6c37337ffa3ee1bc66965d58ef64c1590e5"; hash = "sha256-hI9+KBShsSfvWX7bmRa/1VI20WGat3lDXmbceMZzMS4="; }; cargoHash = "sha256-apOQc9Z6YANoaeKcbNxBfAv7mmGFB+CagrYRPgC5wLY="; strictDeps = true; enableParallelBuilding = true; doCheck = true; nativeBuildInputs = [ pkg-config wrapGAppsHook ]; buildInputs = [ atk cairo gdk-pixbuf glib gtk3 gtk-layer-shell pango ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk.frameworks.Security ] ++ lib.optionals stdenv.isLinux [ wayland ]; preFixup = '' gappsWrapperArgs+=( --prefix ANYRUN_PLUGINS : $out/lib ) ''; postInstall = '' install -Dm444 anyrun/res/style.css examples/config.ron -t $out/share/doc/${pname}/examples/ ''; passthru.updateScript = unstableGitUpdater { }; meta = { description = "A wayland-native, highly customizable runner"; homepage = "https://github.com/kirottu/anyrun"; license = lib.licenses.gpl3Only; maintainers = with lib.maintainers; [ eclairevoyant NotAShelf ]; mainProgram = "anyrun"; }; } </ins>
Code change:
Project description A Steam Achievements Manager for Linux Metadata homepage URL: source URL: license: gpl platforms: inux

Related discussion:
text: <ins> { lib , stdenv , fetchFromGitHub , unstableGitUpdater , curl , gtkmm3 , glibmm , gnutls , yajl , pkg-config }: stdenv.mkDerivation (finalAttrs: { pname = "samrewritten"; version = "unstable-2023-05-23"; src = fetchFromGitHub { owner = "PaulCombal"; repo = "SamRewritten"; # The latest release is too old, use latest commit instead rev = "39d524a72678a226bf9140db6b97641f554563c3"; hash = "sha256-sS/lVY5EWXdTOg7cDWPbi/n5TNt+pRAF1x7ZEaYG4wM="; }; makeFlags = [ "PREFIX=$(out)" ]; nativeBuildInputs = [ pkg-config ]; buildInputs = [ curl gtkmm3 glibmm gnutls yajl ]; passthru.updateScript = unstableGitUpdater { }; meta = { description = "Steam Achievement Manager For Linux. Rewritten in C++"; homepage = "https://github.com/PaulCombal/SamRewritten"; license = lib.licenses.gpl3Plus; maintainers = with lib.maintainers; [ ludovicopiero ]; platforms = lib.platforms.linux; }; }) </ins>
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: clippy, mkShell, makeWrapper, <ins> runCommand, </ins> }: let runtimeExprPath = ./src/eval.nix; nixpkgsLibPath = ../../../lib; <ins> # Needed to make Nix evaluation work inside nix builds initNix = '' export TEST_ROOT=$(pwd)/test-tmp export NIX_CONF_DIR=$TEST_ROOT/etc export NIX_LOCALSTATE_DIR=$TEST_ROOT/var export NIX_LOG_DIR=$TEST_ROOT/var/log/nix export NIX_STATE_DIR=$TEST_ROOT/var/nix export NIX_STORE_DIR=$TEST_ROOT/store # Ensure that even if tests run in parallel, we don't get an error # We'd run into https://github.com/NixOS/nix/issues/2706 unless the store is initialised first nix-store --init ''; </ins> package = rustPlatform.buildRustPackage { name = "nixpkgs-check-by-name";
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: makeWrapper ]; env.NIX_CHECK_BY_NAME_EXPR_PATH = "${runtimeExprPath}"; <del> # Needed to make Nix evaluation work inside the nix build preCheck = '' export TEST_ROOT=$(pwd)/test-tmp export NIX_CONF_DIR=$TEST_ROOT/etc export NIX_LOCALSTATE_DIR=$TEST_ROOT/var export NIX_LOG_DIR=$TEST_ROOT/var/log/nix export NIX_STATE_DIR=$TEST_ROOT/var/nix export NIX_STORE_DIR=$TEST_ROOT/store export NIXPKGS_LIB_PATH=${nixpkgsLibPath} # Ensure that even if tests run in parallel, we don't get an error # We'd run into https://github.com/NixOS/nix/issues/2706 unless the store is initialised first nix-store --init ''; </del> <ins> env.NIXPKGS_LIB_PATH = "${nixpkgsLibPath}"; preCheck = initNix; </ins> postCheck = '' cargo fmt --check cargo clippy -- -D warnings
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: env.NIXPKGS_LIB_PATH = toString nixpkgsLibPath; inputsFrom = [ package ]; }; <ins> # Tests the tool on the current Nixpkgs tree, this is a good sanity check passthru.tests.nixpkgs = runCommand "test-nixpkgs-check-by-name" { nativeBuildInputs = [ package nix ]; nixpkgsPath = lib.cleanSource ../../..; } '' ${initNix} nixpkgs-check-by-name --base "$nixpkgsPath" "$nixpkgsPath" touch $out ''; </ins> }; in package
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: // so the UsesByName ratchet is already as tight as it can be NonAttributeSet => Success(Tight), NonCallPackage => Success(Tight), <del> // This is an odd case when _internalCallByNamePackageFile is used to define a package. </del> <ins> // This is the case when the `pkgs/by-name`-internal _internalCallByNamePackageFile // is used for a package outside `pkgs/by-name` </ins> CallPackage(CallPackageInfo { call_package_variant: Auto, .. <del> }) => NixpkgsProblem::InternalCallPackageUsed { attr_name: attribute_name.clone(), </del> <ins> }) => { // With the current detection mechanism, this also triggers for aliases // to pkgs/by-name packages, and there's no good method of // distinguishing alias vs non-alias. // Using `config.allowAliases = false` at least currently doesn't work // because there's nothing preventing people from defining aliases that // are present even with that disabled. // In the future we could kind of abuse this behavior to have better // enforcement of conditional aliases, but for now we just need to not // give an error. Success(Tight) </ins> } <del> .into(), </del> // Only derivations can be in pkgs/by-name, // so this attribute doesn't qualify CallPackage(CallPackageInfo {
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: text: String, io_error: io::Error, }, <del> InternalCallPackageUsed { attr_name: String, }, </del> MovedOutOfByName { package_name: String, call_package_path: Option<PathBuf>,
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: subpath.display(), text, ), <del> NixpkgsProblem::InternalCallPackageUsed { attr_name } => write!( f, "pkgs.{attr_name}: This attribute is defined using `_internalCallByNamePackageFile`, which is an internal function not intended for manual use.", ), </del> NixpkgsProblem::MovedOutOfByName { package_name, call_package_path, empty_arg } => { let call_package_arg = if let Some(path) = &call_package_path {
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: <ins> self: super: { baz = self.foo; } </ins>
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: <ins> import <test-nixpkgs> { root = ./.; } </ins>
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: <del> pkgs.foo: This attribute is defined using `_internalCallByNamePackageFile`, which is an internal function not intended for manual use. </del>
Code change:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

Related discussion:
text: else [ ]; <ins> # A list optionally containing the `aliases.nix` file from the test case as an overlay # But only if config.allowAliases is not false optionalAliasesOverlay = if (config.allowAliases or true) && builtins.pathExists (root + "/aliases.nix") then [ (import (root + "/aliases.nix")) ] else [ ]; </ins> # All the overlays in the right order, including the user-supplied ones allOverlays = [ autoCalledPackages ] ++ optionalAllPackagesOverlay <ins> ++ optionalAliasesOverlay </ins> ++ overlays; # Apply all the overlays in order to the base fixed-point function pkgsFun