pythonPackages: new and updates #29017
Conversation
|
I will eventually add your PR to #29009. |
Updating to development revision because YouTube broke 0.5.3.1.
Updating to development revision because YouTube broke 0.2.7.1.
oxij
force-pushed
the
pkg/python-packages
branch
from
da704cd
to
845f6fb
Compare
|
Frederik Rietdijk <notifications@github.com> writes:
Can you move the expressions into their own files (see the header of `python-packages.nix`) and use `fetchPypi` where possible.
Done.
|
| @@ -1730,6 +1730,8 @@ in { | |||
| }; | |||
| }; | |||
|
|
|||
| comp = callPackage ../applications/video/comp { }; | |||
There was a problem hiding this comment.
This is an application and should therefore be called directly from all-packages.nix, and not via python-packages.nix.
| @@ -23813,6 +23782,8 @@ EOF | |||
|
|
|||
| wheel = callPackage ../development/python-modules/wheel { }; | |||
|
|
|||
| whitey = callPackage ../applications/video/whitey { }; | |||
There was a problem hiding this comment.
This is an application and should therefore be called directly from all-packages.nix, and not via python-packages.nix.
| maintainers = with maintainers; [ odi ]; | ||
| }; | ||
| }; | ||
| mps-youtube = callPackage ../applications/video/mps-youtube { }; |
There was a problem hiding this comment.
This is an application and should therefore be called directly from all-packages.nix, and not via python-packages.nix.
|
This is an application and should therefore be called directly from `all-packages.nix`, and not via `python-packages.nix`.
I respectfully disagree with that policy. I think things that use
language-specific build system should live near said language-specific
build system. Especially when autogeneration of those package
expressions is possible (and it clearly is possible for most Python
packages present in PyPi, it's just nobody got to implementing it yet).
Haskell, Emacs, Perl, etc use the opposite policy and refer to
applications from `all-packages.nix` with `*Packages.?*.package` when
needed (see, for instance, `git-annex`).
* Why does this policy for Python differs from policies used for
Haskell, Emacs, Perl, etc?
It also makes little sense to move Python applications to
`all-packages.nix` for technical reasons:
* In `python-packages.nix` `callPackage` substitutes python deps, python
programs use a lot of python deps. So it only makes sense to leave
related packages there.
* For Python application that can work under different interpreter
versions you have to select a single interpreter version in
`all-packages.nix`. No such problem in `python-packages.nix`.
* You can always refer to any package from `all-packages.nix` with e.g.
`mps-youtube = python3Packages.mps-youtube` if needed.
To be perfectly honest, I would prefer Python packages to live in a
single file sorted by attribute name, but technical arguments for that
get less and less valid with better SSDs and bigger RAM (unless the
included files are so tiny that `open(2)` costs much more than `read(2)`
followed by parsing).
|
Where do packages live that are written in multiple languages?
Unfortunately it is not possible with Python because:
That's how it was, and how I liked it as well, but we're moving away from that because its problematic, e.g. due to merge conflicts. If we could have autogenerated data, then having a single file with overrides would be nice. But that's not going to happen anytime soon. |
|
Note that while this PR bitrotted much of the exactly the original changes from this PR were merged into master without any discussion on "policy". Doesn't that look hypocritical to you? |
They don't use the stereotypical package-constructing function of any original languagePackages anyway. |
Motivation for this change
"Because YouTube gone complete JavaScript"
lz4: unrelated update, but I'm too lazy to make a separate PR for that.
Things done
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)