Nixpkgs/Modifying Packages: Difference between revisions
imported>Roberth m formatting |
imported>Roberth mNo edit summary |
||
| 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 == | ||