Python: buildPyPIPackage and generated data#16005
Python: buildPyPIPackage and generated data#16005FRidh wants to merge 2 commits intoNixOS:stagingfrom
Conversation
|
A the time of writing the generated JSON is 80 MB. Example usage: By default it picks the latest version. Optionally a version is passed in. I suppose within Nixpkgs we would always be explicit about the versions. |
|
💯 could we get that srcs-pypi repo into nixos organization? and change the name to |
There was a problem hiding this comment.
have to fix meta data appending here
|
@garbas I could rename it, but moving the repo is not up to me. By the way, I think we should keep the discussion in the main repo, that is, this one. That repo is just going to contain generated data, nothing more. |
|
According to #16130 (comment) Hydra cannot build packages that use this because Hydra operates in restricted mode. |
|
I've tested whether a Hydra would build packages that use |
The reason I mentioned this is because we have stable releases to consider. By not specifying explicit versions the |
These two functions wrap respectively buildPythonPackage and buildPythonApplication, but use by default a repository with metadata retrieved from PyPI.
|
If we do not fix the version and upgrade implicitly, would not a lot of applications break all the time? |
|
In my experience with the Python packages we have in Nixpkgs, there's a handful of packages that we need to set the version of explicitly. Most others seem to work fine after (minor) upgrades. And if the update breaks some packages, I would consider that fine as well considering it is Nixpkgs unstable. The amount of time that could be saved would be enormous. |
| , ... } @ attrs: | ||
|
|
||
| let | ||
| pypi-src = fetchgit { |
There was a problem hiding this comment.
Is fetchgit required here?
The good thing about your github structure is, that it is pretty readable.
We could generate a compressed version of your directory structure for downloading automatically via travis-ci.
Maybe putting all packages with the same prefix into the same file and compress the whole thing with xz to reduce the overall size.
There was a problem hiding this comment.
There was a problem hiding this comment.
Is fetchgit required here?
Since GitHub can produce archives for a specific revision we could use fetchurl. But, where we really want to go to is fetchTarbal` along with a sha256. That way, Hydra can evaluate it. Without fetchTarball + sha256 Hydra cannot evaluate it. That's the reason why this is on hold. See also my latest mail.
Another option to reduce the size is to work with two repositories, one that has a JSON for each package, and another one that has package names along with hashes of the JSON files. This repo we would then refer to from Nixpkgs. It would replace downloading a big file with (possibly many) tiny ones.
| pypi = !(builtins.hasAttr "src" attrs || builtins.hasAttr "srcs" attrs); | ||
|
|
||
| # Use Meta data from PyPI | ||
| pypimeta = if pypi then data.meta else {}; |
|
Do you know, what |
|
@Mic92 |
|
I think the way forward is an update script that updates |
Motivation for this change
In #15007 I presented a script to generate metadata from PyPI and a function to build Python packages using that metadata.
In this PR the metadata is no longer stored in Nixpkgs but in an external repository, https://github.com/FRidh/srcs-pypi.
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)These two functions wrap respectively buildPythonPackage and buildPythonApplication, but use by default a repository with metadata retrieved from PyPI.