guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#53395] Fix pypi import for flake8-array-spacing


From: Ludovic Courtès
Subject: [bug#53395] Fix pypi import for flake8-array-spacing
Date: Tue, 25 Jan 2022 14:19:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi Vivien,

Vivien Kraus <vivien@planete-kraus.eu> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>> As a rule of thumb, warnings are one-line messages (not sentences)
>> describing the problem.  Here you could emit such a warning, followed by
>> a call to ‘display-hint’, which accepts Texinfo markup.
> display-hint seems to always add \n\n at the end of the message, is it
> intended that way? Should I do one big display-hint instead of 3?

Yes, just one ‘display-hint’ call, using complete sentences and
paragraphs.  The text should provide an explanation and more importantly
a hint as to what can done, like “The generated package definition might
be wrong; please double-check …”.

You can avoid @strong though, because it doesn’t do
anything useful.

> +        (warning
> +         (G_ "The project name does not appear verbatim in the pypi URI~%"))

I’d make it:

  "project name ~a does not appear verbatim in the PyPI URI~%"

>> Also, what about adding a unit test?

[...]

> +(test-equal "If the package goo is released as foo, the importer warns"
> +  "warning: The project name does not appear verbatim in the pypi URI
> +hint: The project name is: *goo*
> +
> +hint: The pypi URI is: *`https://example.com/foo-1.0.0.tar.gz'*
> +
> +hint: The pypi-uri declaration in the generated package might need to be 
> changed.
> +
> +"
> +  (call-with-output-string
> +    (lambda (port)
> +      (parameterize ((guix-warning-port port)
> +                     (current-error-port port))
> +        ;; Replace network resources with sample data.
> +        (mock ((guix import utils) url-fetch
> +               (lambda (url file-name)
> +                 (match url

These two tests are really integration tests: they exercise the whole
shebang.  I was thinking about having a unit test of just
‘find-project-url’, which is less work (and maintenance :-)) and may be
good enough.

Perhaps you can also change one of the existing python-foo tests to
exercise this bit, for instance by making it “Foo”.

WDYT?

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]