Package 'unitS' requires python39 & requests

[Sam Edge]

On 18/02/2025 00:17, Brian Inglis via Cygwin wrote:
> On 2025-02-17 16:34, Sam Edge via Cygwin wrote:
>> On 17/02/2025 23:21, Brian Inglis via Cygwin wrote:
>>> On 2025-02-17 07:48, Marco Atzeri via Cygwin wrote:
>>>> On 17/02/2025 15:31, Sam Edge via Cygwin wrote:
>>>>> On 17/02/2025 11:29, Federico Kircheis via Cygwin wrote:
>>>>>
>>>>> I mentioned this a while ago but the 'units' package also has a 
>>>>> dependency on 'python39' and 'python39-requests'. This is purely 
>>>>> because of the currency updater script (/usr/bin/unit_cur) I believe.
>>>>>
>>>>> I suspect that most people who want units want it for its physical 
>>>>> unit conversion functionality and the proportion using it for up- 
>>>>> to- date currency conversion is probably pretty small.
>>>>>
>>>>> Considering this, might it be an idea to remove those dependencies?
>>>>>
>>>>
>>>> side effect of our builing tool automatism.
>>>> Removing this type of dependencies is a manual additional operation.
>>>>
>>>> We should modify cygport to allow some dependecies to be excluded.
>>>>
>>>> Time to look on it.
>>>
>>> Similar to other packages like this, we could split into subpackage 
>>> python- units-currency-updater, require it from the main package, and 
>>> announce it will not be automatically installed in the next release, 
>>> and will have to be selected in setup.
>>> In the following release, drop any dependency and announce that.
>>> Or do so in delayed -2 and -3 releases if upstream is not updated, as 
>>> it is sometimes a year or two between updates, often depending on 
>>> changes in standards? See https://ftpmirror.gnu.org/units/ for dates.
>>> I could prep a test release -2 and announcement, and at some future 
>>> time (how long?) if no upstream updates, untest to current stable; 
>>> similarly thereafter with -3?
>>>
>>
>> I think Marco's idea of introducing a mechanism to override the auto- 
>> depends in cygport would make more sense and be more generic.
>>
>> The more long term solution might be to extend the setup.ini (and 
>> setup exe) semantics to have the concepts of 'required' & 'optional' 
>> or 'suggested' packages similar to other package managers. 
>> Considerably more work of course.
> 
> I think we both have cygport patches we maintain locally and have 
> offered which were not incorporated as utility did not outweigh 
> stability nor generality.
> 
> In this case, I would have to manually add the dependency, as there is 
> no deducible connection between the python subpackage and the base 
> subpackage, similar to -doc subpackages, so could easily reverse the 
> dependency from units -> updater to updater -> units.
> 

Splitting the updater script out and have it depend upon units, python3 
& requests sounds like a sensible approach although I don't know how 
much extra fiddling that would require when releasing upstream changes 
next time around. (Sorry, I've not found the time to grok cygport yet. 
So many tools, so little time! ;-))

Thanks.

-- 
Sam Edge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x8AC2CEBF54528E30.asc
Type: application/pgp-keys
Size: 648 bytes
Desc: OpenPGP public key
URL: <https://cygwin.com/pipermail/cygwin/attachments/20250218/afbc0203/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://cygwin.com/pipermail/cygwin/attachments/20250218/afbc0203/attachment.sig>