Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 58.

2024-03-16 Thread Bruno Haible
Hi Collin, > From > experimenting, I've confirmed that calling an invalid program will > throw 'FileNotFoundError'. Other errors should fail loudly so they are > not ignored. Yes, that's how exception-related programming should be done. Thanks. Applied. Bruno

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 58.

2024-03-16 Thread Collin Funk
Hi Bruno, On 3/16/24 9:22 AM, Bruno Haible wrote: > I don't know. Maybe it is related to > https://stackoverflow.com/questions/16981921/relative-imports-in-python-3 ? The import stuff always caused me issues in the past when I used Python. The way we have it now works so I will continue to use it

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 58.

2024-03-16 Thread Bruno Haible
Hi Collin, > This is somewhat related since it deals with imports, but is there a > reason why we don't just import things from modules directly? > > Right now we have: > > from . import constants > # Define global constants. > APP = constants.APP > DIRS = constants.DIRS

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 58.

2024-03-16 Thread Collin Funk
Hi Bruno, On 3/16/24 6:14 AM, Bruno Haible wrote: > Oh, I had not seen that the use of 'classes.' was so inconsistent. > Haven't made up my mind yet, regarding when 'classes.' should be used or not. This is somewhat related since it deals with imports, but is there a reason why we don't just impo

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 58.

2024-03-16 Thread Bruno Haible
Hi Collin, > Let me know how this looks. I've imported CopyAction to main and use > that in a similar way to what you wrote. Nice work. Thanks! Applied. > I've used the name copymode instead of copyaction to match > gnulib-tool.sh. Yes, good. I had forgotten about the distinction between copymo

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 58.

2024-03-15 Thread Collin Funk
-H', '--hardlink', '--more-hardlinks', ...) # rest And similarly for --symlink. CollinFrom 1568aff94b28db067de7d83ccb4630de2e1c4227 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Fri, 15 Mar 2024 19:58:27 -0700 Subject: [PATCH] gnulib-tool.py

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 58.

2024-03-15 Thread Bruno Haible
Hi Collin, > This patch implements --hardlink and --local-hardlink. Thanks; that's major (and tricky), indeed. > Notice the arguments '-s --hardlink --symlink -h'. I tried to make > sure gnulib-tool.py behaved similarly to gnulib-tool.sh in this case. > > I beleive the correct behavior is to us

[PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 58.

2024-03-15 Thread Collin Funk
else: # last_option is --hardlink or equivalent. symlink = False And something similar for the --local-* variants. I think that covers all of the strange hackery for this patch. [1] https://docs.python.org/3/library/argparse.html CollinFrom 3eeea5b376c5e0eceb5378bbbc3876ddbfbdca7c