| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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 eb1369670b5a4e616ff0cf4100616479b1fa3064 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
|
| |
|
|
|
|
|
|
|
|
|
| |
(#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.
|
| | |
|
| |
|
|
| |
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 2dc4ab36772dfaf124af4d90e99c68038f46baa0.
|
| |\
| |
| |
| | |
The nss rebuild isn't so small.
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
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 1e0ebdb8a4fe94db67b6520225d325292d60247c.
|
| |
|
|
| |
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`.
|
| |\| |
|