python.pkgs.glances: add graph support

[timokau]

Motivation for this change

Makes it possible to generate system monitoring graphs. As mentioned in the inline commit, enabling this by default would lead to a significant closure size incerase:

with graph: /nix/store/37wp9rz60sk3cv6hvq282hhgnl89yf73-python3.7-glances-3.0.2       348 277 920
w/o  graph: /nix/store/5m50ba3qlfb2bra5jj098hy4y1pmdqk5-python3.7-glances-3.0.2       128 647 560

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[timokau]

@GrahamcOfBorg build python2.pkgs.glances python3.pkgs.glances

[FRidh]

Is pygal needed during build-time of this package?

[timokau]

No, just runtime.

[FRidh]

I don't see the point of adding options when one can simply include the library to an environment. It saves a rebuild.

[timokau]

True, but

• the user has to know which package is needed for which functionality
• adding it to the environment is impure
• this is somewhat of a special case, since glances provides a binary (not sure why it is in python-packages, probably there is also a library part) and may not be part of a python environment

[FRidh]

Either they need to know a package name, or they need to know a flag for which they need to look at the expression, there isn't much difference.

I think a better solution here is to provide a glances derivation in all-packages.nix that composes an environment. Judging from the README there are a lot of optional dependencies. One could have something similar as say home-assistant. The Python package of glances itself could then stay either here or be moved.

Either python.withPackages is used to build the env, and then another derivation that symlinks only the parts of interest, or PYTHONPATH is set, using makePythonPath. I think here the latter is easiest.

[timokau]

Either they need to know a package name, or they need to know a flag for which they need to look at the expression, there isn't much difference.

I'm hoping that flags / package configuration may become more discoverable in the future. It also scales better with multiple optional dependencies for a feature.

I think a better solution here is to provide a glances derivation in all-packages.nix that composes an environment. Judging from the README there are a lot of optional dependencies. One could have something similar as say home-assistant. The Python package of glances itself could then stay either here or be moved.

I like that solution (although what would be really nice would be some way to express runtimeDependencies that doesn't trigger rebuilds). But wouldn't it be confusing to have two glances packages?

[FRidh]

I'm hoping that flags / package configuration may become more discoverable in the future. It also
scales better with multiple optional dependencies for a feature.

although what would be really nice would be some way to express runtimeDependencies that doesn't trigger rebuilds.

That directly means having a "wrapper" derivation, as I suggested now with glances.

What we would have then are:

• checkInputs for testing
• nativeBuildInputs for building
• installInputs in order to install (satisfy setup.py requirements)
• runtimeInputs for optional dependencies.

In principle we could get rid of installInputs if we tell setup.py to ignore dependencies. That, however, would make it harder to package because you need to check then yourself that you're making available all required runtimeInputs.

But wouldn't it be confusing to have two glances packages?

You could move the current glances expression and hide it in say a let...in expression.

[timokau]

[...]
What we would have then are:

* `checkInputs` for testing

* `nativeBuildInputs` for building

* `installInputs` in order to install (satisfy `setup.py` requirements)

* `runtimeInputs` for optional dependencies.

[...]

Isn't buildInputs (despite the name) already supposed to be
runtimeInputs? Its not enforced, but it should contain the runtime
dependencies.

But wouldn't it be confusing to have two glances packages?

You could move the current glances expression and hide it in say a let...in expression.

That would break existing setups though. Although I can't find any
documentation of using glances as a library, so it doesn't really belong
to python-packages in the first place.

[FRidh]

Yes, installInputs is effectively buildInputs for required runtime dependencies. Something like setuptools and setuptools_scm go in nativeBuildInputs.

[timokau]

This was a thing I needed once and though it might be nice to upstream. Not a high priority for me and I'm not willing to put in more work right now.

Thanks for your review!