From: "Ludovic Courtès" <ludo@gnu.org>
To: Vivien Kraus <vivien@planete-kraus.eu>
Cc: 53395@debbugs.gnu.org
Subject: [bug#53395] Fix pypi import for flake8-array-spacing
Date: Tue, 25 Jan 2022 14:19:05 +0100 [thread overview]
Message-ID: <87y234lzqu.fsf@gnu.org> (raw)
In-Reply-To: <87mtjk22rn.fsf@planete-kraus.eu> (Vivien Kraus's message of "Mon, 24 Jan 2022 23:07:46 +0100")
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’.
next prev parent reply other threads:[~2022-01-25 15:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 19:45 [bug#53395] Fix pypi import for flake8-array-spacing Vivien Kraus via Guix-patches via
2022-01-24 14:05 ` Ludovic Courtès
2022-01-24 22:07 ` Vivien Kraus via Guix-patches via
2022-01-25 13:19 ` Ludovic Courtès [this message]
2022-01-25 16:39 ` Vivien Kraus via Guix-patches via
2022-01-26 15:20 ` bug#53395: " Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y234lzqu.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=53395@debbugs.gnu.org \
--cc=vivien@planete-kraus.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).