Here we go! Ludovic Courtès writes: > 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 …”. I made a new version for that. > > You can avoid @strong though, because it doesn’t do > anything useful. Okay. > >> + (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~%" Changed. > >>> 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. Let’s do both! If you don’t want the integration tests, just delete them (now or when maintenance becomes too demanding). > > Perhaps you can also change one of the existing python-foo tests to > exercise this bit, for instance by making it “Foo”. I added a test function that can be used by all integration tests. It’s not perfect (there’s still a lot of code copied from test to test, and I’m not innocent there too) but I don’t want to change the other tests beyond trivial things. Vivien