diff options
Diffstat (limited to 'nixpkgs/doc/languages-frameworks')
-rw-r--r-- | nixpkgs/doc/languages-frameworks/python.section.md | 82 | ||||
-rw-r--r-- | nixpkgs/doc/languages-frameworks/rust.section.md | 18 |
2 files changed, 74 insertions, 26 deletions
diff --git a/nixpkgs/doc/languages-frameworks/python.section.md b/nixpkgs/doc/languages-frameworks/python.section.md index 41a5dae8b9b0..9b6de47c8e86 100644 --- a/nixpkgs/doc/languages-frameworks/python.section.md +++ b/nixpkgs/doc/languages-frameworks/python.section.md @@ -496,8 +496,8 @@ and in this case the `python35` interpreter is automatically used. ### Interpreters -Versions 2.7, 3.5, 3.6 and 3.7 of the CPython interpreter are available as -respectively `python27`, `python35`, `python36` and `python37`. The aliases +Versions 2.7, 3.5, 3.6, 3.7 and 3.8 of the CPython interpreter are available as +respectively `python27`, `python35`, `python36`, `python37` and `python38`. The aliases `python2` and `python3` correspond to respectively `python27` and `python37`. The default interpreter, `python`, maps to `python2`. The PyPy interpreters compatible with Python 2.7 and 3 are available as `pypy27` and @@ -833,6 +833,7 @@ used in `buildPythonPackage`. - `pythonRemoveBinBytecode` to remove bytecode from the `/bin` folder. - `setuptoolsBuildHook` to build a wheel using `setuptools`. - `setuptoolsCheckHook` to run tests with `python setup.py test`. +- `venvShellHook` to source a Python 3 `venv` at the `venvDir` location. A `venv` is created if it does not yet exist. - `wheelUnpackHook` to move a wheel to the correct folder so it can be installed with the `pipInstallHook`. ### Development mode @@ -1028,36 +1029,43 @@ If you want to create a Python environment for development, then the recommended method is to use `nix-shell`, either with or without the `python.buildEnv` function. -### How to consume python modules using pip in a virtualenv like I am used to on other Operating Systems ? +### How to consume python modules using pip in a virtual environment like I am used to on other Operating Systems? -This is an example of a `default.nix` for a `nix-shell`, which allows to consume a `virtualenv` environment, +While this approach is not very idiomatic from Nix perspective, it can still be useful when dealing with pre-existing +projects or in situations where it's not feasible or desired to write derivations for all required dependencies. + +This is an example of a `default.nix` for a `nix-shell`, which allows to consume a virtual environment created by `venv`, and install python modules through `pip` the traditional way. Create this `default.nix` file, together with a `requirements.txt` and simply execute `nix-shell`. ```nix -with import <nixpkgs> {}; +with import <nixpkgs> { }; let - pythonPackages = python27Packages; -in - -stdenv.mkDerivation { + pythonPackages = python3Packages; +in pkgs.mkShell rec { name = "impurePythonEnv"; + venvDir = "./.venv"; + buildInputs = [ + # A python interpreter including the 'venv' module is required to bootstrap + # the environment. + pythonPackages.python - src = null; + # This execute some shell code to initialize a venv in $venvDir before + # dropping into the shell + pythonPackages.venvShellHook + + # Those are dependencies that we would like to use from nixpkgs, which will + # add them to PYTHONPATH and thus make them accessible from within the venv. + pythonPackages.numpy + pythonPackages.requests - buildInputs = [ - # these packages are required for virtualenv and pip to work: - # - pythonPackages.virtualenv - pythonPackages.pip # the following packages are related to the dependencies of your python # project. # In this particular example the python modules listed in the # requirements.txt require the following packages to be installed locally # in order to compile any binary extensions they may require. - # taglib openssl git @@ -1067,11 +1075,47 @@ stdenv.mkDerivation { zlib ]; + # Now we can execute any commands within the virtual environment + postShellHook = '' + pip install -r requirements.txt + ''; + +} +``` + +In case the supplied venvShellHook is insufficient, or when python 2 support is needed, +you can define your own shell hook and adapt to your needs like in the following example: + +```nix +with import <nixpkgs> { }; + +let + venvDir = "./.venv"; +in pkgs.mkShell rec { + name = "impurePythonEnv"; + buildInputs = [ + python3Packages.python + python3Packages.virtualenv + ... + ]; + + # This is very close to how venvShellHook is implemented, but + # adapted to use 'virtualenv' shellHook = '' - # set SOURCE_DATE_EPOCH so that we can use python wheels SOURCE_DATE_EPOCH=$(date +%s) - virtualenv --python=${pythonPackages.python.interpreter} --no-setuptools venv - export PATH=$PWD/venv/bin:$PATH + + if [ -d "${venvDir}" ]; then + echo "Skipping venv creation, '${venvDir}' already exists" + else + echo "Creating new venv environment in path: '${venvDir}'" + ${pythonPackages.python.interpreter} -m venv "${venvDir}" + fi + + # Under some circumstances it might be necessary to add your virtual + # environment to PYTHONPATH, which you can do here too; + # PYTHONPATH=$PWD/${venvDir}/${python.sitePackages}/:$PYTHONPATH + + source "${venvDir}/bin/activate" pip install -r requirements.txt ''; } diff --git a/nixpkgs/doc/languages-frameworks/rust.section.md b/nixpkgs/doc/languages-frameworks/rust.section.md index 709a0d504cf7..0edf03ad26a9 100644 --- a/nixpkgs/doc/languages-frameworks/rust.section.md +++ b/nixpkgs/doc/languages-frameworks/rust.section.md @@ -32,17 +32,17 @@ Rust applications are packaged by using the `buildRustPackage` helper from `rust ``` rustPlatform.buildRustPackage rec { - name = "ripgrep-${version}"; - version = "0.4.0"; + pname = "ripgrep"; + version = "11.0.2"; src = fetchFromGitHub { owner = "BurntSushi"; - repo = "ripgrep"; - rev = "${version}"; - sha256 = "0y5d1n6hkw85jb3rblcxqas2fp82h3nghssa4xqrhqnz25l799pj"; + repo = pname; + rev = version; + sha256 = "1iga3320mgi7m853la55xip514a3chqsdi1a1rwv25lr9b1p7vd3"; }; - cargoSha256 = "0q68qyl2h6i0qsz82z840myxlnjay8p1w5z7hfyr8fqp7wgwa9cx"; + cargoSha256 = "17ldqr3asrdcsh4l29m3b5r37r5d0b3npq1lrgjmxb6vlx6a36qh"; verifyCargoDeps = true; meta = with stdenv.lib; { @@ -66,7 +66,11 @@ added in `cargoPatches` will also be prepended to the patches in `patches` at build-time. When `verifyCargoDeps` is set to `true`, the build will also verify that the -`cargoSha256` is not out of date by comparing the `Cargo.lock` file in both the `cargoDeps` and `src`. Note that this option changes the value of `cargoSha256` since it also copies the `Cargo.lock` in it. To avoid breaking backward-compatibility this option is not enabled by default but hopefully will be in the future. +`cargoSha256` is not out of date by comparing the `Cargo.lock` file in both the +`cargoDeps` and `src`. Note that this option changes the value of `cargoSha256` +since it also copies the `Cargo.lock` in it. To avoid breaking +backward-compatibility this option is not enabled by default but hopefully will +be in the future. ### Building a crate for a different target |