[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’.