Nixpkgs/Modifying Packages - Revision history

Fidgetingbits: Add link and tweak styling

2024-10-19T15:10:02Z

Add link and tweak styling

← Older revision		Revision as of 15:10, 19 October 2024
Line 1:		Line 1:
	To modify the behavior of a Nix package, you typically have more than one option. The first approach you may consider is changing its runtime configuration: passing command line options, environment variables or configuration files that exist outside the package itself. Not modifying the definition of a package has the benefit of being able to use the publicly available Hydra build cache.		To modify the behavior of a Nix package, you typically have more than one option. The first approach you may consider is changing its runtime configuration: passing command line options, environment variables or configuration files that exist outside the package itself. Not modifying the definition of a package has the benefit of being able to use the publicly available [[Hydra\|Hydra]] build cache.

	If the software as packaged does not have the flexibility you need, you have various options.		If the software as packaged does not have the flexibility you need, you have various options.
Line 7:		Line 7:
	If you expect your changes to be generally useful to others, you may consider creating a pull request for [https://github.com/NixOS/nixpkgs nixpkgs on github]. This has the benefit that others can help maintaining the package and that a binary of your package will be available for you to download.		If you expect your changes to be generally useful to others, you may consider creating a pull request for [https://github.com/NixOS/nixpkgs nixpkgs on github]. This has the benefit that others can help maintaining the package and that a binary of your package will be available for you to download.

	If upstreaming into the official NixPkgs is not an option, consider creating an overlay. This is slightly more involved at first, but is easier to maintain than a ~~NixPkgs~~ fork and, unlike a fork, it can be combined with other overlays. In an overlay, you can also choose not to redefine the package, but only override part of the arguments or derivation attributes. For example, you may only need to change one of the [https://nixos.org/nixpkgs/manual/#sec-stdenv-phases stdenv build phases].		If upstreaming into the official NixPkgs is not an option, consider creating an overlay. This is slightly more involved at first, but is easier to maintain than a Nixpkgs fork and, unlike a fork, it can be combined with other overlays. In an overlay, you can also choose not to redefine the package, but only override part of the arguments or derivation attributes. For example, you may only need to change one of the [https://nixos.org/nixpkgs/manual/#sec-stdenv-phases stdenv build phases].

	== The Copy Paste Option ==		== The Copy Paste Option ==

imported>Nix: link to overlays page

2021-09-20T15:20:11Z

link to overlays page

← Older revision		Revision as of 15:20, 20 September 2021
Line 34:		Line 34:
	== Create an Overlay ==		== Create an Overlay ==

	Overlays are a composable method of managing packages that are not (or not yet) suitable for upstream NixPkgs. Unlike a fork, you can have multiple active overlays and you can make changes to packages without having to maintain a git fork of the entire repository.		[[Overlays]] are a composable method of managing packages that are not (or not yet) suitable for upstream NixPkgs. Unlike a fork, you can have multiple active overlays and you can make changes to packages without having to maintain a git fork of the entire repository.

	[https://github.com/basvandijk/nixtodo/blob/master/default.nix Nixtodo] has an example of using an overlay to structure the packages in a web application project.		[https://github.com/basvandijk/nixtodo/blob/master/default.nix Nixtodo] has an example of using an overlay to structure the packages in a web application project.

	[https://github.com/mozilla/nixpkgs-mozilla Nixpkgs-mozilla] is an example of an overlay containing alternative and extra open source software.		[https://github.com/mozilla/nixpkgs-mozilla Nixpkgs-mozilla] is an example of an overlay containing alternative and extra open source software.

imported>Makefu: Makefu moved page Modifying a Package to Nixpkgs/Modifying Packages: move to subsection of nixpkgs

2018-03-19T18:30:38Z

Makefu moved page Modifying a Package to Nixpkgs/Modifying Packages: move to subsection of nixpkgs

← Older revision		Revision as of 18:30, 19 March 2018
(No difference)

imported>Roberth at 10:17, 6 December 2017

2017-12-06T10:17:03Z

← Older revision		Revision as of 10:17, 6 December 2017
Line 26:		Line 26:
	It is not as flexible as the original definition though. If you want to reuse hello as a dependency of another package, you will have to work with two methods of injecting dependencies. Instead of just the standard <code>callPackage</code> function, your packages have to specify exactly where their dependencies come from, which can become a burden of its own. Also it is impossible to use this package with something other than the default <code><nixpkgs></code>, default NixPkgs configuration, default system architecture etc.		It is not as flexible as the original definition though. If you want to reuse hello as a dependency of another package, you will have to work with two methods of injecting dependencies. Instead of just the standard <code>callPackage</code> function, your packages have to specify exactly where their dependencies come from, which can become a burden of its own. Also it is impossible to use this package with something other than the default <code><nixpkgs></code>, default NixPkgs configuration, default system architecture etc.

	So this method of modifying a package is only suited for prototyping a package before refactoring and ad-hoc packages you know you will not re-use.		So this method of modifying a package is only suited for prototyping a package before refactoring and ad-hoc packages you know you will not re-use. Please consider the other options, because they don't have those drawbacks.

	== Upstreaming into NixPkgs ==		== Upstreaming into NixPkgs ==

imported>Roberth: formatting

2017-12-06T10:04:45Z

formatting

← Older revision		Revision as of 10:04, 6 December 2017
Line 9:		Line 9:
	If upstreaming into the official NixPkgs is not an option, consider creating an overlay. This is slightly more involved at first, but is easier to maintain than a NixPkgs fork and, unlike a fork, it can be combined with other overlays. In an overlay, you can also choose not to redefine the package, but only override part of the arguments or derivation attributes. For example, you may only need to change one of the [https://nixos.org/nixpkgs/manual/#sec-stdenv-phases stdenv build phases].		If upstreaming into the official NixPkgs is not an option, consider creating an overlay. This is slightly more involved at first, but is easier to maintain than a NixPkgs fork and, unlike a fork, it can be combined with other overlays. In an overlay, you can also choose not to redefine the package, but only override part of the arguments or derivation attributes. For example, you may only need to change one of the [https://nixos.org/nixpkgs/manual/#sec-stdenv-phases stdenv build phases].

	== The Copy Paste Option		== The Copy Paste Option ==

	This one is quick and easy to understand, but not something you can build on.		This one is quick and easy to understand, but not something you can build on.
Line 28:		Line 28:
	So this method of modifying a package is only suited for prototyping a package before refactoring and ad-hoc packages you know you will not re-use.		So this method of modifying a package is only suited for prototyping a package before refactoring and ad-hoc packages you know you will not re-use.

	== Upstreaming into NixPkgs		== Upstreaming into NixPkgs ==

	Making your changes available as open source has all the benefits of open source. If it's an option for you, fork [https://github.com/NixOS/nixpkgs nixpkgs on github], read the contributing guidelines, edit and test your modified clone and create a pull request.		Making your changes available as open source has all the benefits of open source. If it's an option for you, fork [https://github.com/NixOS/nixpkgs nixpkgs on github], read the contributing guidelines, edit and test your modified clone and create a pull request.

	== Create an Overlay		== Create an Overlay ==

	Overlays are a composable method of managing packages that are not (or not yet) suitable for upstream NixPkgs. Unlike a fork, you can have multiple active overlays and you can make changes to packages without having to maintain a git fork of the entire repository.		Overlays are a composable method of managing packages that are not (or not yet) suitable for upstream NixPkgs. Unlike a fork, you can have multiple active overlays and you can make changes to packages without having to maintain a git fork of the entire repository.

imported>Roberth: Expand on the options in the introduction

2017-12-06T10:03:55Z

Expand on the options in the introduction

← Older revision		Revision as of 10:03, 6 December 2017
Line 8:		Line 8:

	If upstreaming into the official NixPkgs is not an option, consider creating an overlay. This is slightly more involved at first, but is easier to maintain than a NixPkgs fork and, unlike a fork, it can be combined with other overlays. In an overlay, you can also choose not to redefine the package, but only override part of the arguments or derivation attributes. For example, you may only need to change one of the [https://nixos.org/nixpkgs/manual/#sec-stdenv-phases stdenv build phases].		If upstreaming into the official NixPkgs is not an option, consider creating an overlay. This is slightly more involved at first, but is easier to maintain than a NixPkgs fork and, unlike a fork, it can be combined with other overlays. In an overlay, you can also choose not to redefine the package, but only override part of the arguments or derivation attributes. For example, you may only need to change one of the [https://nixos.org/nixpkgs/manual/#sec-stdenv-phases stdenv build phases].

			== The Copy Paste Option

			This one is quick and easy to understand, but not something you can build on.

			Let's add a patch to GNU hello by duplicating its definition. In the NixPkgs repository, hello can be found in <code>pkgs/applications/misc/hello/default.nix</code>, but it is not an expression that can be built directly with <code>nix-build</code> or <code>nix-env -i</code>. Its dependencies need to be injected, so let's wrap it in <code>callPackage</code>

			<syntaxhighlight>
			let pkgs = import <nixpkgs> {};
			in pkgs.callPackage (
			# whatever is in hello.nix
			) {}
			</syntaxhighlight>

			This is a Nix expression you can build, install, or base a Nix shell on.

			It is not as flexible as the original definition though. If you want to reuse hello as a dependency of another package, you will have to work with two methods of injecting dependencies. Instead of just the standard <code>callPackage</code> function, your packages have to specify exactly where their dependencies come from, which can become a burden of its own. Also it is impossible to use this package with something other than the default <code><nixpkgs></code>, default NixPkgs configuration, default system architecture etc.

			So this method of modifying a package is only suited for prototyping a package before refactoring and ad-hoc packages you know you will not re-use.

			== Upstreaming into NixPkgs

			Making your changes available as open source has all the benefits of open source. If it's an option for you, fork [https://github.com/NixOS/nixpkgs nixpkgs on github], read the contributing guidelines, edit and test your modified clone and create a pull request.

			== Create an Overlay

			Overlays are a composable method of managing packages that are not (or not yet) suitable for upstream NixPkgs. Unlike a fork, you can have multiple active overlays and you can make changes to packages without having to maintain a git fork of the entire repository.

			[https://github.com/basvandijk/nixtodo/blob/master/default.nix Nixtodo] has an example of using an overlay to structure the packages in a web application project.

			[https://github.com/mozilla/nixpkgs-mozilla Nixpkgs-mozilla] is an example of an overlay containing alternative and extra open source software.

imported>Roberth: Extract from LSB Discussion

2017-12-06T09:22:34Z

Extract from LSB Discussion

New page

To modify the behavior of a Nix package, you typically have more than one option. The first approach you may consider is changing its runtime configuration: passing command line options, environment variables or configuration files that exist outside the package itself. Not modifying the definition of a package has the benefit of being able to use the publicly available Hydra build cache.

If the software as packaged does not have the flexibility you need, you have various options.

Conceptually the most simple option is to duplicate the package definition in a local file where you make your changes. You will be able to install and use it locally, while only having to learn the basics of Nix packaging.

If you expect your changes to be generally useful to others, you may consider creating a pull request for [https://github.com/NixOS/nixpkgs nixpkgs on github]. This has the benefit that others can help maintaining the package and that a binary of your package will be available for you to download.

If upstreaming into the official NixPkgs is not an option, consider creating an overlay. This is slightly more involved at first, but is easier to maintain than a NixPkgs fork and, unlike a fork, it can be combined with other overlays. In an overlay, you can also choose not to redefine the package, but only override part of the arguments or derivation attributes. For example, you may only need to change one of the [https://nixos.org/nixpkgs/manual/#sec-stdenv-phases stdenv build phases].