Commit Graph

66 Commits

Author SHA1 Message Date
Jon
15b3d9d277
python3Packages.venvShellHook: add postVenvCreation (#87850)
* python3Packages.venvShellHook: add postVenvCreation

* python: docs: add postVenvCreation explaination
2020-05-16 09:34:11 +02:00
Benjamin Hipple
c88290789c doc: Rewrite python onboarding tutorials in manual
Based on some feedback in #87094 and discussion with @fridh, this re-organizes
the onboarding tutorial in the Nixpkgs manual's python section, so that we start
with the simplest, most ad-hoc examples and work our way up. This progresses
from:

1. How to create an temporary python env at the cmdline, then
2. How to create a specific python env for a single script, then
3. How to create a specific python env for a project in a shell.nix, then
4. How to install a specific python env globally on the system or in a user profile.

Additionally, I've tried to standardize on some of the "best practice" ways of
doing things:

1. Instead of saying that this command style is "supported but strongly not
   discouraged", I've just deleted it to avoid confusion.

   Bad:  nix-shell -p python38Packages.numpy python38Packages.toolz
   Good: nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz ])'

2. In the portion where we show how to add stuff to the user's
   `XDG_CONFIG_HOME`, use overlays instead of `config.nix`. The former can do
   everything the latter can do, but is also much more generic and powerful,
   because it can compose with other files, compose with other envs, compose
   with overlays that do things like swap whether tensorflow and pytorch are
   built openblas/mkl/cuda stacks, and so on. The user is eventually going to
   see the overlay, so to avoid confusion let's standardize on it.
2020-05-15 22:43:16 +02:00
Benjamin Hipple
c3e2f98779 doc: use idiomatic overlay names in the python manual example
An overlay by any other name would function just as well, but we generally use
`self: super:` for the regular overlays, and `python-self: python-super`.
2020-05-09 18:02:20 -04:00
Benjamin Hipple
c0f434fcc8 doc: update python manual to reference python 3.8 instead of 3.5
Improvement suggested in #87094
2020-05-09 12:58:00 -04:00
Frederik Rietdijk
ca2fd28d83 Revert "docs/python: document builders using doInstallCheck and not doCheck (#86051)"
For disabling tests when overriding, use `.overridePythonAttrs`.

Discussion about aliasing `.overridePythonAttrs` to `.overrideAttrs`.
https://github.com/NixOS/nixpkgs/pull/82772

This reverts commit 35812875a4455e2636eb24ddaf702faa4767fafa.
2020-04-26 16:22:33 +02:00
Doron Behar
35812875a4
docs/python: document builders using doInstallCheck and not doCheck (#86051) 2020-04-26 11:53:06 +00:00
Matthew Bauer
3c41d61514 doc/overlays.xml: update documentation for BLAS/LAPACK
This expands the documentation and explains how to assert LP64.
2020-04-21 11:03:10 -05:00
Pavol Rusnak
fadcfc3ea4
treewide: per RFC45, remove more unquoted URLs 2020-04-18 14:04:37 +02:00
Jonathan Ringer
3990b914c3 manual: use quoted homepage urls 2020-02-16 09:49:12 -08:00
Benjamin Hipple
4988805287 doc: consistent formatting on python manual section
No material changes to docs, but trying to sanitize them for consistent
readability prior to looking at #75837.

- Use `*` for lists instead of `-`. I have no opinion one way or the other, but
  the latter was only used in 1-2 places.
- Pad the code blocks with whitespace.
- Wrap to 80 characters, except for a few 1-liners that were only slightly over.
2020-02-09 11:23:11 -05:00
Dima
e9ba4b94fb doc: python: fixing mistake in venv example
When updating the section to python 3 some places still
referred to pythonPackages and were overlooked.
Decided to switch it to be more similar to the first
example binding pythonPackages and clarified comments a
bit based on confusion I observed on IRC.

Related to https://github.com/NixOS/nixpkgs/pull/77569
2020-02-02 09:39:58 -08:00
Dima
25d0d2b5e8 doc: python: refreshing virtualenv section for venv
Updating section about imperative use of ad-hoc virtual-environments for
use of pythons built-in `venv` module via venvShellHook.  Also trying to
make it a bit friendlier to beginners by adding a bit more explanation
to the code snippet and some remarks old-school virtualenv.

Adjusting for venvShellHook and adding manual example

Adding pip install and replacing python2 example with python3
2020-01-20 18:01:12 -08:00
Frederik Rietdijk
eba1f79418 pythonPackages.venvShellHook: init
This is a hook that loads a virtualenv from the specified `venvDir`
location. If the virtualenv does not exist, it is created.
2020-01-14 22:36:21 +01:00
Frederik Rietdijk
eb1369670b Revert "python3: now points to python38"
This is going to require more work.

This reverts commit 2dc4ab36772dfaf124af4d90e99c68038f46baa0.
2020-01-10 10:33:40 +01:00
Vladimír Čunát
5c780036c5
Merge branch 'master' into staging-next
The nss rebuild isn't so small.
2020-01-08 22:48:13 +01:00
adisbladis
2d6f1ff4dd
python: Add support for installing Python eggs 2020-01-08 13:59:04 +00:00
Frederik Rietdijk
2dc4ab3677 python3: now points to python38 2020-01-04 15:27:48 +01:00
Frederik Rietdijk
07ceb05628 Docs: document we have python38 2020-01-04 15:27:03 +01:00
Daiderd Jordan
0159151705
manual: specify interpreter in virtualenv shell
Without this virtualenv might try to setup an environment for a
different version of python then the one specified in the expression.
2019-12-17 16:42:18 +01:00
Arnout Engelen
7eddc92374 documentation: show combining python35.withPackages and mkShell
this had me stumped - thanks to adisbladis on irc
2019-11-13 16:44:26 +01:00
Stig Otnes Kolstad
3265f554ca doc: fix tiny typo 2019-10-24 08:29:33 +02:00
Anders Riutta
1f7b1cf581 doc/python: clarify python nix tooling efforts
@garbas and @seppeljordan, are these updates correct?

I removed `offlinehacker/pypi2nix` as an unmaintained ancestor of the current repo `nix-community/pypi2nix`. It appears @garbas forked `offlinehacker/pypi2nix` to `garbas/pypi2nix` and then handed off maintainership to @seppeljordan, transferring the repo to `nix-community/pypi2nix`.
2019-10-14 09:54:01 +01:00
Frederik Rietdijk
f7e28bf5d8 Split buildPythonPackage into setup hooks
This commit splits the `buildPythonPackage` into multiple setup hooks.

Generally, Python packages are built from source to wheels using `setuptools`.
The wheels are then installed with `pip`. Tests were often called with
`python setup.py test` but this is less common nowadays. Most projects
now use a different entry point for running tests, typically `pytest`
or `nosetests`.

Since the wheel format was introduced more tools were built to generate these,
e.g. `flit`. Since PEP 517 is provisionally accepted, defining a build-system
independent format (`pyproject.toml`), `pip` can now use that format to
execute the correct build-system.

In the past I've added support for PEP 517 (`pyproject`) to the Python
builder, resulting in a now rather large builder. Furthermore, it was not possible
to reuse components elsewhere. Therefore, the builder is now split into multiple
setup hooks.

The `setuptoolsCheckHook` is included now by default but in time it should
be removed from `buildPythonPackage` to make it easier to use another hook
(curently one has to pass in `dontUseSetuptoolsCheck`).
2019-09-06 15:18:45 +02:00
Frederik Rietdijk
7da15d9b36 buildPythonPackage: add support for setupPyGlobalFlags (2) 2019-07-15 17:47:57 +02:00
Frederik Rietdijk
271b57c219 Revert "buildPythonPackage: add support for setupPyDistFlags"
I merged this a bit too quick. We need to have a closer look at it.
See the points brought up in https://github.com/NixOS/nixpkgs/pull/64682.

This reverts commit 1e0ebdb8a4fe94db67b6520225d325292d60247c.
2019-07-13 13:25:32 +02:00
Kirill Boltaev
1e0ebdb8a4 buildPythonPackage: add support for setupPyDistFlags
Flags passed to the "python setup.py" command.
2019-07-13 09:47:00 +02:00
Frederik Rietdijk
f1ff85e61d Docs Python: fix example on how to override the package set
Not passing in the newly created interpreter as `self` results in an
incorrect `passthru`. Solves #64334.
2019-07-05 13:56:03 +02:00
Tom McLaughlin
7f3d805e1c Add documentation for recent permitUserSite change (#61502) 2019-05-15 08:27:59 +02:00
Linus Heckemann
b3d9da5f0a doc: fix syntax error in python documentation 2019-04-25 22:37:53 +02:00
cdyson37
6ea4aa481d
python-docs: typo 2019-04-23 10:37:10 +01:00
Daniel Schaefer
bac4d95aa2 treewide: Change URLs to HTTPS
Lots of URLs were HTTP redirect to HTTPS. Changed those and checked them
if there's actual content. Inspired by
https://github.com/NixOS/nixpkgs/issues/60004
2019-04-22 10:19:54 +02:00
worldofpeace
0ccfebf9f2 fix Including a derivation using callPackage
The example didn't use pkgs.
2019-03-24 05:33:07 -04:00
worldofpeace
94a409450a fixup! doc/python: cleanup examples, references 2019-03-24 05:29:53 -04:00
worldofpeace
63f244193b doc/python: cleanup examples, references 2019-03-22 22:50:30 -04:00
Felix Biggs
1e86c0a7df doc/python: remove unnecessary let statement 2019-03-22 22:20:55 -04:00
Frederik Rietdijk
1fccd25595 buildPythonPackage: always export LANG=C.UTF-8 2019-02-23 20:08:26 +01:00
Frederik Rietdijk
e7b4608d02 buildPythonPackage: initial support for PEP 517 2019-02-23 20:05:19 +01:00
Frederik Rietdijk
b4acd97729 buildPython*: enable strictDeps 2019-02-17 14:40:48 +01:00
Benjamin Hipple
6206a342e0 mkl: include Intel's libiomp.so in the MKL RPM unpack
Since Intel's default openmp implementation is available in the same src
tarball, we can just include it in the package. This means that `mkl` now "just
works" without any environment variables, fragile setup-hooks, or forced
propagation.

Since the openmp implementation is only needed at runtime (and for test cases),
users can substitute a different one if they prefer by exporting it with
`LD_PRELOAD`, which is how Intel recommends handling this. If they do not do so,
`libiomp.so` lives next to `libmkl_rt.so` and thus will be in the RPATH as a
sane default.

Since this still comes from the same src tarball, we can ship it without losing
the fixed-output derivation; likewise, since Hydra is not building or caching
these, shipping these proprietary packages costs no bandwidth for the nix
community.
2018-12-19 22:05:22 +01:00
Anders Kaseorg
85379a29ec pypy3: init at 6.0.0
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
2018-12-19 09:53:31 +01:00
Frederik Rietdijk
7863aae5b2 Merge master into staging-next 2018-11-11 08:59:44 +01:00
Benjamin Hipple
a649f1c0cd doc: fix default python interpreter
The default for `python3` is currently `python36`.
2018-11-10 13:00:10 -05:00
Frederik Rietdijk
53d00c3351 Merge master into staging-next 2018-11-10 11:08:54 +01:00
Frederik Rietdijk
b1bdce0793 python34: remove
Python 3.4 will receive it's final patch release in March 2019 and there won't
be any releases anymore after that, so also not during NixOS 2019.03.

Python 3.4 is not used anymore in Nixpkgs. In any case, migrating code from
3.4 to 3.4+ is trivial.
2018-11-04 18:48:24 +01:00
Vladimír Čunát
a92a2c8e15
Merge branch 'master' into staging
Conflict: rename of pythondaemon -> python-daemon.
2018-11-02 14:40:14 +01:00
Benjamin Hipple
baf0703010 pythonPackages.pythondaemon: rename to pythonPackages.python-daemon
This commit renames the pythondaemon module to match its module name, github
name, and pypi name, which makes it easier to find and reference. In order to
avoid breaking any external users, I've left an alias with a deprecated warning.
2018-10-30 21:09:34 +01:00
Frederik Rietdijk
0f38d9669f python3 is now python37 instead of python36
With Python 3.7 now at 3.7.1, and Python 3.6 at it's final maintenance
mode release, it is time to move on to 3.7 as the default interpreter.
2018-10-24 20:05:44 +02:00
Chris Ostrouchov
277b73ab6f pythonPackages.{numpy,scipy,numexpr}: support MKL as BLAS
This adds support building with MKL.
2018-10-20 11:50:37 +02:00
Benjamin Hipple
1bcdf27c48 Update with code review feedback; add example python application 2018-10-12 10:06:25 +02:00
Benjamin Hipple
c0af13f1c8 python: update documentation
This touches up a handful of places in the python documentation to try to make
the current best-practices more obvious. In particular, I often find the
function signatures (what to pass, what not to pass) confusing and have added
them to the docs.

Also updated the metas to be more consistent with the most frequently used
modern style.
2018-10-12 10:06:25 +02:00