[bug#44988] [PATCH] gnu: vdirsyncer: Use a more recent version of python-requests-toolbelt.

[bug#44988] [PATCH] gnu: vdirsyncer: Use a more recent version of python-requests-toolbelt.

[Tanguy Le Carrour]

Hi Guix!

The reason for this patch is that `vdirsyncer` conflicts with some
packages using a more recent version of `python-requests-toolbelt`. For instance `poetry`.

But suddenly, I'm not sure any more that this is the proper way of fixing this
kind of problem…

Suggestions welcome!


* gnu/packages/dav.scm (vdirsyncer)[propagated-inputs] Use python-requests-toolbelt-0.9.1 instead of python-requests-toolbelt.
---
 gnu/packages/dav.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/dav.scm b/gnu/packages/dav.scm
index 8692a49c50..616569b006 100644
--- a/gnu/packages/dav.scm
+++ b/gnu/packages/dav.scm
@@ -169,7 +169,7 @@ efficient syncing
      `(("python-atomicwrites" ,python-atomicwrites)
        ("python-click-log" ,python-click-log)
        ("python-click-threading" ,python-click-threading)
-       ("python-requests-toolbelt" ,python-requests-toolbelt)))
+       ("python-requests-toolbelt" ,python-requests-toolbelt-0.9.1)))
     (synopsis "Synchronize calendars and contacts")
     (description "Vdirsyncer synchronizes your calendars and addressbooks
 between two storage locations.  The most popular purpose is to
-- 
2.29.2

[bug#44988] [PATCH] gnu: vdirsyncer: Use a more recent version of python-requests-toolbelt.

[Ludovic Courtès]

Hi,

Tanguy Le Carrour <tanguy@bioneland.org> skribis:

> The reason for this patch is that `vdirsyncer` conflicts with some
> packages using a more recent version of `python-requests-toolbelt`. For instance `poetry`.
>
> But suddenly, I'm not sure any more that this is the proper way of fixing this
> kind of problem…

You mean that it conflicts when installing those packages all in the
same profile?

Overall the criterion should be to choose a version that works well with
vdirsyncer, and to be consistent in the package collection.  IOW, the
non-default version of ‘python-requests-toolbelt’ should be the
exception.

Does that make sense?

Ludo’.

[bug#44988] [PATCH] gnu: vdirsyncer: Use a more recent version of python-requests-toolbelt.

[Tanguy LE CARROUR]

Hi,


Excerpts from Ludovic Courtès's message of December 6, 2020 11:24 pm:
> Tanguy Le Carrour <tanguy@bioneland.org> skribis:
>> The reason for this patch is that `vdirsyncer` conflicts with some
>> packages using a more recent version of `python-requests-toolbelt`. For instance `poetry`.
>>
>> But suddenly, I'm not sure any more that this is the proper way of fixing this
>> kind of problem…
> 
> You mean that it conflicts when installing those packages all in the
> same profile?

Yeah, sorry, I should have included the error message!

```
$ guix package -i poetry
The following package will be installed:
   poetry 1.1.4

guix package: error: profile contains conflicting entries for python-requests-toolbelt
guix package: error:   first entry: python-requests-toolbelt@0.9.1 /gnu/store/gqx0ssh217cczj3fi88k5545mcb8cn80-python-requests-toolbelt-0.9.1
guix package: error:    ... propagated from poetry@1.1.4
guix package: error:   second entry: python-requests-toolbelt@0.8.0 /gnu/store/9pgb39jybc823cbr0ajqp93cxnh2pn4m-python-requests-toolbelt-0.8.0
guix package: error:    ... propagated from vdirsyncer@0.16.8
hint: Try upgrading both `poetry' and `vdirsyncer', or remove one of them from the profile.
```


> Overall the criterion should be to choose a version that works well with
> vdirsyncer, and to be consistent in the package collection.  IOW, the
> non-default version of ‘python-requests-toolbelt’ should be the
> exception.
> Does that make sense?

Yes it does! Thanks… but I'm still struggling with the why and when
of package versions! But, as it is related to my questions in
"Poetry upgrade and related packages", I'll elaborate there!

Regards,

-- 
Tanguy

bug#44988: [PATCH] gnu: vdirsyncer: Use a more recent version of python-requests-toolbelt.

[Tanguy LE CARROUR]

See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52099.


-- 
Tanguy