bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Collin Funk
Subject: Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 58.
Date: Sat, 16 Mar 2024 12:21:05 -0700
User-agent: Mozilla Thunderbird

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.
Might be something I look into in the future though.

> This typically requires experimentation. (Same problem as in other
> programming languages/environments.) ...
> It depends. If you can get away with catching a smaller set of exceptions,
> it's better.

I see, thanks. I am most comfortable with C so the exception stuff is
sort of new to me. I've used Java and C++ a few years ago but not for
anything complex.

> This idiom is more widely applicable, indeed: It works also for commands
> that may produce warnings.

I've submitted a new patch that tries to copy the behavior of
gnulib-tool.sh. In my original patch I had a misunderstanding of
'git update-index --refresh'.

$ git update-index --refresh
gnulib-tool.py: needs update
$ echo $?
1

For some reason I thought that the message was stderr and the exit
code was zero. Now that I have corrected that misunderstanding, I
don't think there is a need to do fancy subprocess module stuff:

    if copymode == classes.CopyAction.Hardlink or lcopymode == 
classes.CopyAction.Hardlink:
        # Setting hard links modifies the ctime of files in the gnulib checkout.
        # This disturbs the result of the next "gitk" invocation.
        # Workaround: Let git scan the files. This can be done through
        # "git update-index --refresh" or "git status" or "git diff".
        if isdir(joinpath(APP['root'], '.git')):
            try:
                sp.run(['git', 'update-index', '--refresh'],
                       cwd=APP['root'], stdout=sp.DEVNULL)
            except FileNotFoundError:
                # No 'git' program was found.
                pass

I've fixed the condition from the original patch, since we only care
if hard links were used. Then the subprocess documentation says the
most common exception is 'OSError' [1]. This is a parent class to many
different exceptions corresponding to 'errno' values [2]. From
experimenting, I've confirmed that calling an invalid program will
throw 'FileNotFoundError'. Other errors should fail loudly so they are
not ignored.

[1] https://docs.python.org/3/library/subprocess.html#exceptions
[2] https://docs.python.org/3/library/exceptions.html#os-exceptions

Collin

Attachment: 0001-gnulib-tool.py-Fix-git-update-index-call-when-using-.patch
Description: Text Data


reply via email to

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