| Commit message (Collapse) | Author | Age |
... | |
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Maybe there was an idea behind this separation, but looking at the
contents I don't see any reason for these being separate.
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Reorganize the chapters into parts and reduce the TOC depth to make the
TOC useful again. The top-level TOC is very brief, but that is fine
because every part will have its own TOC.
Section titles of languages/frameworks are also simplified to just
the name of the language/framework.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
@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`.
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
One issue with cargoSha256 is that it's hard to detect when it needs to
be updated or not. It's possible to upgrade a package and forget to
update cargoSha256 and run with old versions of the program or
libraries.
This commit introduces `verifyCargoDeps` which, when enabled, will check
that the Cargo.lock is not out of date in the cargoDeps by comparing it
with the package source.
|
| | |
| | |
| | |
| | | |
This reverts commit f8a8fc6c7c079de430fa528f688ddac781bcef16.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 41af38f3728bd64b80721c44ed1fb019978cbc1b, reversing
changes made to f0fec244ca380b9d3e617ee7b419c59758c8b0f1.
Let's delay this. We have some serious regressions.
|
| |\ \
| | |/
| |/| |
gtk3.setupHook: clear icon-theme.cache in preFixup
|
| | | |
|
| | | |
|
| |\ \
| | |/
| |/| |
|
| | |\
| | | |
| | | | |
doc: replaced outdated config reference `build-use-sandbox` with `san…
|
| | | | |
|
| | |/ |
|
| |\| |
|
| | | |
|
| |\| |
|
| | | |
|
| |\| |
|
| | |\
| | | |
| | | | |
citrix-receiver: decomission in favor of citrix-workspace.
|
| | | |
| | | |
| | | |
| | | | |
Already documented in #64645
|
| | |/ |
|
| | | |
|
| |/ |
|
| |\
| | |
| | | |
doc: add GNOME
|
| | |
| | |
| | |
| | | |
Examples are updated to commits that use them as well.
|
| | | |
|
| | |
| | |
| | |
| | | |
Closes: #16285
|
|/ /
| |
| |
| |
| | |
That is because this commit should be merged to both master and
release-19.09.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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`).
|
|\ \
| | |
| | |
| | | |
Fixed trivial conflicts caused by removing rec.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a new package that provides a shell hook to make it easy to
declare manpages and shell completions in a manner that doesn't require
remembering where to actually install them. Basic usage looks like
{ stdenv, installShellFiles, ... }:
stdenv.mkDerivation {
# ...
nativeBuildInputs = [ installShellFiles ];
postInstall = ''
installManPage doc/foobar.1
installShellCompletion --bash share/completions/foobar.bash
installShellCompletion --fish share/completions/foobar.fish
installShellCompletion --zsh share/completions/_foobar
'';
# ...
}
See source comments for more details on the functions.
|
|\| | |
|
| |/
| |
| |
| | |
Co-authored-by: Alyssa Ross <hi@alyssa.is>
|
|\| |
|
| |
| |
| |
| | |
These have been deprecated for a long time now and has not seen much maintenance.
|
| | |
|
|\| |
|
| |\
| | |
| | | |
Androidenv fixes
|
| | |
| | |
| | |
| | |
| | |
| | | |
This system type was previously broken but is now fixed.
Add it here to showcase the common task of launching a fully-fledged Android
system with an included app store.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This setup hook modifies a Perl script so that any "-I" flags in its shebang
line are rewritten into a "use lib ..." statement on the next line. This gets
around a limitation in Darwin, which will not properly handle a script whose
shebang line exceeds 511 characters.
|