The documentation incorrectly stated that `installFlags` are passed to
`pip install`.

Note this also means python3Minimal is now also Python 3.8.

This reverts commit eb1369670b and adds more.

* python3Packages.venvShellHook: add postVenvCreation

* python: docs: add postVenvCreation explaination

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.

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`.

Improvement suggested in #87094

For disabling tests when overriding, use `.overridePythonAttrs`.

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

This reverts commit 35812875a4.

This expands the documentation and explains how to assert LP64.

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.

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

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

This is a hook that loads a virtualenv from the specified `venvDir`
location. If the virtualenv does not exist, it is created.

This is going to require more work.

This reverts commit 2dc4ab3677.

Without this virtualenv might try to setup an environment for a
different version of python then the one specified in the expression.

this had me stumped - thanks to adisbladis on irc

@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`.

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`).

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 1e0ebdb8a4.

Flags passed to the "python setup.py" command.

Not passing in the newly created interpreter as `self` results in an
incorrect `passthru`. Solves #64334.

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

The example didn't use pkgs.

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.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>

The default for `python3` is currently `python36`.

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.

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.

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.

This adds support building with MKL.