guix-patches
[Top][All Lists]
Advanced

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

[bug#62202] [PATCH v4 6/6] tests: juliahub: Add unit tests for (guix imp


From: Nicolas Graves
Subject: [bug#62202] [PATCH v4 6/6] tests: juliahub: Add unit tests for (guix import juliahub).
Date: Tue, 16 Apr 2024 21:11:49 +0200

On 2024-04-16 18:52, Ludovic Courtès wrote:

> Hi,
>
> Nicolas Graves <ngraves@ngraves.fr> skribis:
>
>> I'm currently writing it, it'll result in a handy helper for tests, such
>> as :
>>
>> (with-git-forge  ; spawns a dumb but functional git server
>>       '(("MyPackage" . ((add "a.txt" "A")
>>                         (commit "First commit")
>>                         (tag "v1.0.0" "Release 1.0"))))
>>     (with-julia-test-servers
>>         `(("/juliahub/MyPackage/" 200 ,juliahub-redirect.html)
>>           ("/juliahub/MyPackage/" 200 ,juliahub-redirect.html)
>>           ("/juliahub/MyPackage/MySlg/1.0.0/pkg.json" 200
>>            ,(lambda (port) (display (fixture-pkg.json) port)))
>>           ("/general/M/MyPackage/Package.toml" 200
>>            ,(lambda (port) (display (pk 'd (general-Package.toml)) port))))
>>       (juliahub->guix-package "MyPackage")))
>
> Nice!
>
>> However, for that I'll need the http server to be able to respond with a
>>          (content-type . (application/x-git-upload-pack-advertisement))
>> header to git. But in guile's web server implementation, this is not
>> possible because of sanitize-response's charset addition, which is not
>> configurable. 
>
> D’oh.  I’m not sure what this is about; it’s definitely possible to add
> pretty much any ‘content-type’ header (we do that in ‘guix publish’ for
> instance), but if it’s going too far, then maybe you should go back to
> procedure mocks.

Just to write that in a clearer way:

libgit2, which is behind guile-git, expects this exact header or fails,
with no additional charset field. The sanitize-response function in the
guile web server implementation on its side ensures that a charset field
is added no matter what.

So indeed we can set

   (content-type . (application/x-git-upload-pack-advertisement))
    
but in reality guile-git // libgit2 will read

   (content-type . (application/x-git-upload-pack-advertisement
                     (charset . "utf-8"))
                     
and will fail in this case. 

Since it's exterior (expected by libgit2), I thought the more relevant
would be to allow more flexibility on the guile web server side. But if
you think it's way better to ask on the libgit2 or guile-git side, I'll
be happy to.  WDYT ?

>
>> That's outside my field, how can we progress further ? We do indeed need
>> such a server to properly test juliahub since we go get the tag from the
>> actual repo (this is justified in the patch series).
>>
>> _____________________________________________________________________________
>> ;;; Git Forge = Git HTTP Server with Dump transfer protocol and repositories
>
> This work’s not lost: we can definitely switch back to it when the
> limitations you encountered has been fixed on the Guile side, and/or in
> other, simpler cases.
>
> Thanks!
>
> Ludo’.

-- 
Best regards,
Nicolas Graves





reply via email to

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