Hi, For some packages we get this: --8<---------------cut here---------------start------------->8--- $ guix import pypi jaxlib guix import: error: no source release for pypi package jaxlib 0.1.67 --8<---------------cut here---------------end--------------->8--- and indeed, there’s no “sdist” (source distribution), only “bdist_wheel” (.whl files). Nevertheless, should the importer do something smarter here? The metadata at <https://pypi.org/pypi/jaxlib/json> doesn’t contain info about the source repository (though it contains the home page at github.com). Would it make sense to build from a .whl file or does this necessarily include generated code and other byproducts? Thanks, Ludo’.
Wheels are (as far as I understand) binary distributions, so they ought to contain everything, that gets put into site-packages. I don't think they make for good source packages. In particular, the jaxlib wheel contains a bunch of shared objects and almost none of the source that one can see on Github. Instead of erroring out, we could try to check whether the homepage points to a git forge and try to generate a git-reference from that. Failing this, we might want to set source to something, that produces an error when read or when used as a variable, similar to how unknown licenses are handled. Regards, Leo
Hi, Leo Prikler <leo.prikler@student.tugraz.at> skribis: > Wheels are (as far as I understand) binary distributions, so they ought > to contain everything, that gets put into site-packages. I don't think > they make for good source packages. In particular, the jaxlib wheel > contains a bunch of shared objects and almost none of the source that > one can see on Github. Uh, worse than I thought. > Instead of erroring out, we could try to check whether the homepage > points to a git forge and try to generate a git-reference from that. Sounds good. I suspect special-casing github.com would already catch most cases… Problem is that we would not know which tag to use, unless we go to great lengths to guess that. > Failing this, we might want to set source to something, that produces > an error when read or when used as a variable, similar to how unknown > licenses are handled. Right; not failing seems preferable. Thanks, Ludo’.
Hi,
Ludovic Courtès <ludo@gnu.org> writes:
[...]
>> Failing this, we might want to set source to something, that produces
>> an error when read or when used as a variable, similar to how unknown
>> licenses are handled.
>
> Right; not failing seems preferable.
That seems to be the most actionable thing to do. It'd help when
importing recursively; the whole collections could still be imported
fully (although requiring manual intervention) instead of erroring-out
half-way.
Maxim
Hi! So for now I “fixed” it by displaying a hint in commit 00762a4c4c8ecdd71cccf6afdd87ae68bf9b4964. --8<---------------cut here---------------start------------->8--- $ ./pre-inst-env guix import pypi jaxlib guix import: error: no source release for pypi package jaxlib 0.1.76 hint: This indicates that the package is available on PyPI, but only as a "wheel" containing binaries, not source. To build it from source, refer to the upstream repository at `https://github.com/google/jax'. --8<---------------cut here---------------end--------------->8--- Ludo’.
Hi,
Ludovic Courtès <ludo@gnu.org> writes:
> Hi!
>
> So for now I “fixed” it by displaying a hint in commit
> 00762a4c4c8ecdd71cccf6afdd87ae68bf9b4964.
>
> $ ./pre-inst-env guix import pypi jaxlib
> guix import: error: no source release for pypi package jaxlib 0.1.76
>
> hint: This indicates that the package is available on PyPI, but only as a "wheel" containing
> binaries, not source. To build it from source, refer to the upstream repository at
> `https://github.com/google/jax'.
That's much clearer, thanks!
Maxim