guix-patches
[Top][All Lists]
Advanced

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

[bug#34729] [PATCH v2] gnu: libgit2: Avoid Python.


From: Ludovic Courtès
Subject: [bug#34729] [PATCH v2] gnu: libgit2: Avoid Python.
Date: Mon, 18 Mar 2019 10:40:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hello Danny,

Danny Milosavljevic <address@hidden> skribis:

> On Mon, 11 Mar 2019 22:38:07 +0100
> Ludovic Courtès <address@hidden> wrote:
>
>> Danny Milosavljevic <address@hidden> skribis:
>> 
>> > * gnu/packages/patches/libgit2-avoid-python.patch: New file.
>> > * gnu/local.mk (dist_patch_DATA): Add it.
>> > * gnu/packages/version-control.scm (libgit2)[source]: Use it.
>> > [inputs]: Remove python.
>> > [native-inputs]: Add guile-2.2.  
>> 
>> So the goal is to remove Python from libgit2’s *build-time*
>> dependencies, right?  (Python is not a run-time dependency for libgit2
>> according to ‘guix size libgit2’.)  Can you explain a bit more?  :-)
>
> It's listed as regular input, though (for no reason).
>
> We use git for quite basic things in Guix (especially since we usually
> use git to fetch packages from github) and we had some problems
> with Python 2 (since fixed).  So Andreas, Ricardo and me looked at what
> on Earth libgit2 needs Python for and found that it's just one smallish
> file used at build time.
>
> Hence the replacement :)

I see, that makes sense!

>> This is really cool, but at the same time I feel like we’d rather have a
>> compelling reason to start maintaining a parallel implementation of
>> their test suite machinery.
>
> Sure, it makes sense to think about who's going to maintain it.
>
> In this case it's just a test case collector which basically does
>
> $ grep -r "void.*test_" .
>
> so I think the risk of it diverging is low.  If it after all does diverge
> (and we notice it), we can always replace it by the Python version again.
>
> It's pretty much a 1:1 port of the original (it's so long because
> I made both the structure and the output the same), so it should be
> easy to track future changes.
>
> libgit2 bundled it from an upstream project, "clar".  That also usually
> means that the bundled copy gets updated less often.

OK, well let’s do that, then.  Please make sure to add comments in the
patch that explain the rationale, things we must pay attention to when
updating (if any), etc.

> We could also try upstreaming it.

Well, you could try, but I have a feeling that this wouldn’t be
fruitful.  :-)

Thank you!

Ludo’.





reply via email to

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