yogsototh/mach-nix
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Readme: improve style & fix typo

Browse source
This commit is contained in:
kwzrd 2021-02-14 12:21:54 +01:00
parent f967f0fd51
commit 01c3ff9b74
No known key found for this signature in database
GPG key ID: 414B5564B87D848D
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
Readme.md
View file

@ -119,7 +119,7 @@ Functions for building python environments:
1. **mkPython** - builds a python environment for a given `requirements.txt`.
1. **mkPythonShell** - builds a python environment suitable for nix-shell.
1. **mkDockerImage** - builds a layered docker image containing a python environment.
1. **mkNixpkgs** - returns nixpkgs which is conform to the given requirements.
1. **mkNixpkgs** - returns nixpkgs which conform to the given requirements.
1. **mkOverlay** - returns an overlay function to make nixpkgs conform to the given requirements.
1. **mkPythonOverrides** - produces pythonOverrides to make python conform to the given requirements.
@ -127,7 +127,7 @@ Functions for building python packages or applications:
1. **buildPythonPackage** - build a single python package from a source code while automatically detecting requirements.
1. **buildPythonApplication** - same as **buildPythonPackage**, but package will not be importable by other python packages.
**buildPythonPackage** and **buildPythonApplication** accept the same arguments like their equally named partners in nixpkgs, plus the arguments of **mkPython**. If name/version/requirements arguments are omitted, mach-nix attempts to detect them automatically. See [./examples.md](/examples.md).
**buildPythonPackage** and **buildPythonApplication** accept the same arguments as their equally named partners in nixpkgs, plus the arguments of **mkPython**. If name/version/requirements arguments are omitted, mach-nix attempts to detect them automatically. See [./examples.md](/examples.md).
**mkPython** and all other **mk...** functions take exactly the following arguments:
@ -173,12 +173,12 @@ Providers can be disabled/enabled/preferred like in the following examples:
Mach-nix will always satisfy the **requirements.txt** fully with the configured providers or fail with a **ResolutionImpossible** error.
If a mach-nix build fails, Most of the times it can be resolved by just switching the provider of a package, which is simple and doesn't require writing a lot of nix code. For some more complex scenarios, checkout the [./examples.md](/examples.md).
If a mach-nix build fails, most of the time it can be resolved by just switching the provider of a package, which is simple and doesn't require writing a lot of nix code. For some more complex scenarios, checkout the [./examples.md](/examples.md).
## Why nix?
Usually people rely on multiple layers of different package management tools for building their software environments. These tools are often not well integrated with each other and don't offer strong reproducibility. Example: You are on debian/ubuntu and use APT (layer 1) to install python. Then you use venv (layer 2) to overcome some of your layer 1 limitations (not being able to have multiple versions of the same package installed) and afterwards you are using pip (layer 3) to install python packages. You notice that even after pinning all your requirements, your environment behaves differently on your server or your colleagues machine because their underlying system differs from yours. You start using docker (layer 4) to overcome this problem which adds extra complexity to the whole process and gives you some nasty limitations during development. You need to configure your IDE's docker integration and so on. Despite all the effort you put in, still the problem is not fully solved and from time to time your build pipeline just breaks and you need to fix it manually.
In contrast to that, the nix package manager provides a from ground up different approach to build software systems. Due to it's purly functional approach, nix doesn't require additional layers to make your software reliable. Software environments built with nix are known to be reproducible, and portable, which makes many processes during development and deployment easier. Mach-nix leverages that potential by abstracting away the complexity involved in building python environments with nix. Basically it just generates nix expressions for you.
In contrast to that, the nix package manager provides a from ground up different approach to build software systems. Due to its purely functional approach, nix doesn't require additional layers to make your software reliable. Software environments built with nix are known to be reproducible, and portable, which makes many processes during development and deployment easier. Mach-nix leverages that potential by abstracting away the complexity involved in building python environments with nix. Basically it just generates nix expressions for you.
## How does mach-nix work?
The general mechanism can be broken down into [Dependency resolution](#dependency-resolution) and [Generating a nix expression](#generating-a-nix-expression):