bug#49168: ‘guix import pypi’ misses package dependencies

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

> So I came up with the following patch, which adds a flag for optional
> dependencies, based on ‘requires.txt’.
>
> Unfortunately, it has no effect for ‘guix import pypi tablib’ because we
> only look at Wheel info in that case, as per:
>
>   ;; First, try to compute the requirements using the wheel, else, fallback to
>   ;; reading the "requires.txt" from the egg-info directory from the source
>   ;; archive.
>   (or (guess-requirements-from-wheel)
>       (guess-requirements-from-source))
>
> AFAICS, wheels don’t provide that info, do they?
>
> Why does the importer favor .whl in the first place?  Is it supposed to
> be more accurate or more widespread or something?

Yes, the METADATA file from the binary wheel is a better place to look
than the source egg-info requires.txt file.  In my commit 01589acc5e1, I
simplified a comment that used used to read as:

-  ;; First, try to compute the requirements using the wheel, since that is the
-  ;; most reliable option. If a wheel is not provided for this package, try
-  ;; getting them by reading either the "requirements.txt" file or the
-  ;; "requires.txt" from the egg-info directory from the source tarball. Note
-  ;; that "requirements.txt" is not mandatory, so this is likely to fail.
+  ;; First, try to compute the requirements using the wheel, else, fallback to
+  ;; reading the "requires.txt" from the egg-info directory from the source
+  ;; tarball.

The wheel (.whl) binary format is well specified as PEP 427 [0] and is
what pip primarily uses for installing Python packages, making it a very
reliable source of metadata.  The Python egg is the predecessor of the
wheel, and can be considered obsolete, which explains why it's used as a
fallback.

Perhaps it'd be best to raise the issue to the package maintainers and
have them specify their metadata correctly?

Having the code you wrote to allow importing optional dependencies is
still a nice (optional) option to have though.  It was originally left
out based on comments from Ricardo that it wouldn't make a good default
due to raising the packaging effort.

HTH,

Maxim

[0]  https://www.python.org/dev/peps/pep-0427/