-cache.m4 files).
2024-08-29 Bruno Haible
gnulib-tool.py: Allow verifying license compatibility with GPLv2+.
* pygnulib/GLInfo.py (GLInfo.usage): Document the --gpl option.
* pygnulib/main.py (main): Accept a --gpl option. Pass it to the
GLConfig.
* pygnulib
As mentioned in
<https://lists.gnu.org/archive/html/bug-gnulib/2024-08/msg00018.html>,
$ ./gnulib-tool --extract-dependents hamt
should return
hamt-tests
This patch does it.
2024-08-16 Bruno Haible
gnulib-tool.py: Correct the result of --extract-dependents.
* py
When gnulib-tool --create-testdir is used with option --without-tests,
the Python implementation creates a wrong result. See:
$ rm -rf ../testdir1; ./gnulib-tool.sh --create-testdir --dir=../testdir1
--without-tests fstrcmp
$ rm -rf ../testdir2; ./gnulib-tool.py --create-testdir --dir
Collin Funk wrote:
> > The latter invocation should list hamt-tests.
>
> Sure, no problem. I assume that since the 'module-tests' is implicit we
> just have to check for the existence of f'{self.name}-tests'.
Yes.
> > does not complete within a reasonable time.
>
> Yeah, that is the main reason
Bruno Haible writes:
> While doing that, if you could also please fix the relation between
> module and module -tests?
>
> $ ./gnulib-tool --extract-dependencies hamt-tests
> hamt
>
> $ ./gnulib-tool --extract-dependents hamt
> (none)
>
> The latter invocation should list hamt-tests.
Sure, no p
Hi Collin,
> Eventually I'll have a look at simplifying GLModule.getDependents.
> Adding tests beforehand of course so I don't break it.
While doing that, if you could also please fix the relation between
module and module -tests?
$ ./gnulib-tool --extract-dependencies hamt-tests
hamt
$ ./gnul
Hi Bruno,
Bruno Haible writes:
> It was intentional: I think a function that returns a set[GLModule] is
> more reusable than a function that returns a string.
>
>> Now that I think of it I'm not sure why I return a string there. I think
>> it is better to return a set and let the caller sort as
an a function that returns a string.
> Now that I think of it I'm not sure why I return a string there. I think
> it is better to return a set and let the caller sort as they wish,
> format for printing, etc.
You're right. Done:
2024-08-03 Bruno Haible
Hi Bruno,
Thanks for your recent patch gnulib-tool.py. I didn't really look at it
until now.
One minor correction I applied. The GLModule.getDependentsRecursively
function returns 'set[GLModule]' not 'str'.
The function looks similar to a function I wrote that do
rticular module. I've missed a corresponding gnulib-tool option for a
long time. This patch adds it. So that you can now write
./gnulib-tool -h --create-testdir --dir foo $(./gnulib-tool
--extract-dependents c99)
2024-07-28 Bruno Haible
gnulib-tool.py: New optio
In gnulib-tool.py, error 3 is "configure file does not exist", not
"module doesn't exist".
2024-07-28 Bruno Haible
gnulib-tool.py: Fix an exception message.
* pygnulib/GLModuleSystem.py (GLModuleSystem.find): Raise error 23,
not 3.
Paul Eggert writes:
> Right, but the glitch is worth documenting. I installed the attached
> into Autoconf.
Thanks!
Collin
On 6/2/24 14:51, Collin Funk wrote:
I don't know enough about Autotools to tell if anything silly can be
done using this trick. Not that you would run auto* in a project that
you don't trust anyways...
Right, but the glitch is worth documenting. I installed the attached
into Autoconf.From 3a7a
> It's OK now to make small changes to the output of gnulib-tool.py,
> and change the unit tests accordingly.(*) This will make the unit
> tests fail with GNULIB_TOOL_IMPL=sh, but it is no longer important
> since the shell implementation is only maintained for a diminishing
> set of users.
Sounds good, thanks.
Collin
ment any more that
GNULIB_TOOL_IMPL=sh+py works in all cases.
This strict "same output" check was useful before we switched
to the Python implementation by default, and in the few weeks
afterwards.
It's OK now to make small changes to the output of gnulib-tool.py,
and change the uni
Hi Collin,
> Agreed, I reverted that patch and pushed it before it causes any
> trouble [1].
Thanks!
> Do you still expect GNULIB_TOOL_IMPL=sh+py to pass by the way?
Sure. We need to give users a year, at least, for migrating from
the shell to the Python implementation. And when they migrate,
i
Bruno Haible wrote:
> Yes, that's my point. Instead of using unnormalized file names nearly
> everywhere and normalized file names only in a few places, it is better
> to use normalized file names nearly everywhere and unnormalized file names
> only in a few places. It causes fewer bugs and less he
Collin Funk wrote:
> But I am still confused about what the point of 'newtail' is:
>
> def joinpath(head: str, *tail: str) -> str:
> '''Join two or more pathname components, inserting '/' as needed. If any
> component is an absolute path, all previous path components will be
> discarde
Bruno Haible wrote:
>> I never really looked at the joinpath() function so I just realized it
>> essentially does os.path.normpath(os.path.join(...)) unlike what it's
>> doc string says.
>
> "unlike what the doc string says"? What do you mean by that? The doc string
> said "This function also repl
Hi Collin,
> I never really looked at the joinpath() function so I just realized it
> essentially does os.path.normpath(os.path.join(...)) unlike what it's
> doc string says.
"unlike what the doc string says"? What do you mean by that? The doc string
said "This function also replaces SUBDIR/../ w
houldn't cause any issues building.
CollinFrom 790206bfe741d1280b0b5734a0d4070b26a885ab Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Fri, 14 Jun 2024 21:55:48 -0700
Subject: [PATCH] gnulib-tool.py: Simplify joining paths.
* pygnulib/constants.py (joinpath): Remove function. It is equival
Collin Funk wrote:
> Lets just use os.path.isabs() and let it deal with
> platform related stuff.
OK.
I assume that if someone uses gnulib-tool with Cygwin, and has a
native Windows Python installation, they will report problems. Then
we can decide what to do. (Probably there are few people who d
2024-06-09 Collin Funk
+
+ gnulib-tool.py: Handle absolute path checks consistently.
+ * pygnulib/GLImport.py (GLImport.relative_to_destdir)
+ (GLImport.relative_to_currdir): Use os.path.isabs() instead of checking
+ for a slash.
+ * pygnulib/constants.py (symlin
700
Subject: [PATCH] gnulib-tool.py: Don't perform unnecessary configure.ac
scanning.
* pygnulib/GLImport.py (GLImport.execute): Use re.search() instead of
re.findall() since we only care about finding one match. Remove
unnecessary bool() calls.
---
ChangeLog| 7 +++
pygnulib/GLI
Collin Funk wrote:
> Good point. I've pushed this patch adding a set() around that one call.
Thanks.
> This comment is interesting:
>
> # We need NO_EXPENSIVE_WARN_CFLAGS, because with gcc 13, the compilation of
> # libxml/parser.c requires 1.9 GB of RAM with -fanalyzer, as opposed to
> #
the optimization
> in _extract_lib_SOURCES.
Good point. I've pushed this patch adding a set() around that one call.
Collin
>From c1cdc5ef8ef8b22d46bf55d8cb992f0b75532b46 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Mon, 3 Jun 2024 04:57:14 -0700
Subject: [PATCH] gn
Hi Collin,
> Oops yes. Good point, I must have overlooked that. It appears that it
> will be O(n²). In this loop [1] and the else branch of
> "PyAnySet_Check(other)" [2].
Thanks for checking.
> The lists there seem small enough that I doubt it matters too much.
Bad excuse :) You haven't seen th
Hi Bruno,
Bruno Haible writes:
> The variable mentioned_files in pygnulib/GLModuleSystem.py line 599
> was a set and is now a list. Is the expression
> lib_files.difference(mentioned_files)
> therefore being evaluated more slowly (as O(n²) where it was O(n) before)?
> That is, does Python iter
his comment style but gnulib-tool.sh handles it (line 3453-3466).
> So gnulib-tool.py should too.
Thanks! Yes, gnulib-tool should handle this.
The variable mentioned_files in pygnulib/GLModuleSystem.py line 599
was a set and is now a list. Is the expression
lib_files.difference(mentione
st is the same issue as
yesterdays patch. Variables with a trailing comment, e.g.
lib_SOURCES += file.c file.h # comment
are not matched. As far as I can tell none of the module descriptions
have this comment style but gnulib-tool.sh handles it (line 3453-3466).
So gnulib-tool.py should too.
The
Collin Funk wrote:
> Thanks, I've applied the attached patch fixing that regular expression.
Thanks. Now it appears to work fine.
Bruno
t/tree/bin/autoreconf.in#n532
>From 1372dc1631053fa72bbf5755cbc89f63cbffec33 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sun, 2 Jun 2024 05:29:33 -0700
Subject: [PATCH] gnulib-tool.py: Fix regular expression (regr. today).
* pygnulib/main.py (main) [import]: Match all characters until &
Hi Collin,
> > Thanks for this recipe. I think this is worth a unit test, since it
> > is a special case that is otherwise not tested.
>
> Agreed. I can add one later today.
I added it already.
Bruno
Hi Bruno,
Bruno Haible writes:
> Thanks for this recipe. I think this is worth a unit test, since it
> is a special case that is otherwise not tested.
Agreed. I can add one later today.
> The regular expression doesn't seem right:
[...]
> The point of using a non-greedy operator is to not incl
Hi Collin,
> Not sure how this didn't get found sooner, to be honest. Here is an
> example of the bug:
>
> $ git clone https://git.savannah.gnu.org/git/rcs.git
> $ cd rcs
> $ git checkout next
> $ sh -x autogen.sh
Thanks for this recipe. I think this is worth a unit test, since i
src/gnulib/.gnulib-tool.py", line 30, in
main.main_with_exception_handling()
File "/home/collin/.local/src/gnulib/pygnulib/main.py", line 1382, in
main_with_exception_handling
main(temporary_directory)
File "/home/collin/.local/src/gnulib/pygnulib/main.py&
Collin Funk wrote:
> I've committed this patch adding the ASCII flag.
Thanks.
a look at seeing if re.ASCII is applicable to
those too.
Collin
>From 1b74469a3aaa1a4bbe94272fde87c2335afb89e1 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Wed, 29 May 2024 02:35:02 -0700
Subject: [PATCH] gnulib-tool.py: Don't emit non-ASCII shell output.
Reported by Bruno Haible in
<http
Hi Bruno,
Bruno Haible writes:
> But that's not the same thing: The previous code made sure that
> module names with non-ASCII characters use the MD5 hash code.
> The new code does not:
>
re.match(re.compile(r'^[abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_]*$'),'abcäöü')
>
Hi Collin,
> -# List of characters allowed in shell identifiers.
> -shell_id_chars: ClassVar[str] =
> 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_'
> +# Regular expression matching module names that can be used as shell ids.
> +shell_id_pattern: ClassVar[re.Pat
to write a docstring...
I've pushed this patch fixing it.
Also, I've added a comment about the '\n' following the module name. One
might be tempted to remove it. However, when using
--conditional-dependencies that would cause gnulib-tool.sh a
pygnulib/GLModuleSystem.py | 48 --
2 files changed, 20 insertions(+), 38 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a405680df3..9be0407793 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-05-28 Collin Funk
+
+ gnulib-tool.py
needs the same fix.
2024-05-08 Bruno Haible
gnulib-tool.py: Make --megatest behaviour more similar to shell impl.
* pygnulib/main.py (main) [megatest]: Remove space from the testdir
name.
diff --git a/pygnulib/main.py b/pygnulib/main.py
index 8462916653..585f7df43f 10
Hi Collin,
> I've pushed the attached patch. In gnulib-tool.sh the following is
> done:
>
> ../configure || func_exit 1
> $MAKE || func_exit 1
> [...]
>
> So here we can just use sp.run([command, arg], check=True) and exit if
> an exception occurs.
Thanks. I confirm that --test now
On 5/8/24 12:47 AM, Collin Funk wrote:
>> With .sh, both fail. With .py, both succeed. Looks like a bug in
>> gnulib-tool.py: When the 'make' or 'make check' step fails, the entire
>> command should fail.
>
> I see what you mean. I'll have a look at
insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index 21f4039dfe..b752fde065 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-05-07 Collin Funk
+
+ gnulib-tool.py: Handle module dependencies that cannot be found.
+ * pygnulib/GLModuleSystem.py
Hi Collin,
> > Hmm. Is that refactoring, that you are imagining, intrusive? ...
>
> Depends on the specific warning being addressed. :)
>
> There are more trivial cases like GLMakeFileTable which stores
> information as a dictionary. We have a table of makefile variables:
>
> table: list[d
I forgot to mention: the pattern to provide re-usable GitLab CI/CD
definitions that I'm inspired by is Debian's pipeline project:
https://salsa.debian.org/salsa-ci-team/pipeline/
It is easy to setup a new project to use their reusable pipeline -- just
add the CI/CD configuration file setting poin
Bruno Haible writes:
> gnulib-tool is used is many CI jobs. Just adding 'python3' to the
> prerequisites of such a job makes it run faster. Here are the execution
> times for a single run, before and after adding 'python3', for those
> CIs that I maintain or co-maintain. In minutes and seconds.
>
gnulib-tool is used is many CI jobs. Just adding 'python3' to the
prerequisites of such a job makes it run faster. Here are the execution
times for a single run, before and after adding 'python3', for those
CIs that I maintain or co-maintain. In minutes and seconds.
On 5/4/24 8:17 AM, Bruno Haible wrote:
>> For CI, I am thinking it is best to ignore the typing warnings for the
>> time being. Since gnulib-tool.py needs a bit more refactoring for that
>> to be helpful. It was written before typing was a thing. :)
>
> Hmm. Is that r
Collin Funk wrote:
> For CI, I am thinking it is best to ignore the typing warnings for the
> time being. Since gnulib-tool.py needs a bit more refactoring for that
> to be helpful. It was written before typing was a thing. :)
Hmm. Is that refactoring, that you are imagining, intrusive
ation that runs at least once a week?
>>
>> Hmm, I like that idea. I would have to find what tool works best for
>> that.
>
> Yes, please.
Right now I am leaning towards mypy. It seems to be the best at
detecting errors/potential errors.
For CI, I am thinking it is best to
Hi Collin,
> > Can you please add, to the first line of the ChangeLog entry, a note
> > that tells us when the regression was introduced? Such as
> >(regression 2024-xx-xy)
> > or
> >(regr. yesterday)
> ...
> I've never modified a ChangeLog entry before. Is the proper way to
> just modify
On 5/3/24 6:03 PM, Bruno Haible wrote:
>> In main.py a call to mkdtemp() was the use of the 'tempfile' module
>> prefix.
>
> Oh, that would have led to a runtime error, right?
Yes, it would only be seen if it entered the section of code where
modules have an incompatible license. So the program w
Hi Collin,
> In main.py a call to mkdtemp() was the use of the 'tempfile' module
> prefix.
Oh, that would have led to a runtime error, right?
Can you please add, to the first line of the ChangeLog entry, a note
that tells us when the regression was introduced? Such as
(regression 2024-xx-xy)
or to that. Just in case of that, I put back the 'glpy' prefix.
CollinFrom b86d31ade5e8284df1efe339890b674eedf89bcd Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Fri, 3 May 2024 17:26:18 -0700
Subject: [PATCH] gnulib-tool.py: Fix an undefined function name.
Hi Collin,
> ... It seems like a pain to track
> down every code path that can lead to 'sys.exit()' or 'exit()' with a
> temporary directory still existing.
> ...
> Therefore, we can use tempfile.TemporaryDirectory as a context manager
> and let Python cleanup for us [1]:
>
> def main_with_excep
Collin Funk wrote:
> I noticed that the file names when running 'patch' on test-driver
> weren't quoted. I guess that would cause problems in practice if you
> used spaces in directories
Indeed. Thanks for fixing that!
> Since we assume POSIX shells we can just use shlex.quote() to deal
> with an
It looks like gnulib-tool.py never cleaned up temporary directories
for modes other than the --import, --create-testdir, and related.
Since the --extract-* functions seem less used, hopefully this hasn't
caused too much spam yet.
In gnulib-tool-tests:
$ rm -rf /tmp/glpy*
$ ./test-a
Wed, 1 May 2024 21:26:34 -0700
Subject: [PATCH] gnulib-tool.py: Quote file names passed to 'patch'.
* pygnulib/GLTestDir.py (_patch_test_driver): Import shlex and cleanup
unused imports. Use shlex.quote() on the file names passed to 'patch'.
* pygnulib/GLFileSystem.py (GLFileSystem
Collin Funk wrote:
> Since 'module' is pretty much always a GLModule, I have renamed these
> to 'module_name'.
+1
..
Since 'module' is pretty much always a GLModule, I have renamed these
to 'module_name'.
CollinFrom ecdab13fca9f61cdfa832005c9324414621b4069 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Wed, 1 May 2024 02:21:43 -0700
Subject: [PATCH 2/2] gnulib-tool.py: Fi
:00 2001
From: Collin Funk
Date: Wed, 1 May 2024 01:12:18 -0700
Subject: [PATCH] gnulib-tool.py: Use the GLModule's name variable directly.
* pygnulib/GLModuleSystem.py (GLModule.getName): Remove function.
(GLModule.__str__, GLModule.__repr__, GLModule.isNonTests)
(GLModule.repeatModul
Hi Bruno,
On 4/30/24 12:44 AM, Bruno Haible wrote:
> Yes, it's a good sign, and most probably a consequence of the testing
> with various packages [1][2] that we did.
And the test suite that you wrote. Many thanks for working on that for
me.
Also, thanks for testing all the projects who use cvs.
I pushed the attached patch. It should have removed all the remaining
unused instance variables. -3 GLConfig's to worry about.
CollinFrom 134f6b8a1806b1bcf0d1cd96ffe97e0d249d4581 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Tue, 30 Apr 2024 01:09:55 -0700
Subject: [PATCH] gnulib-to
Collin Funk wrote:
> Hopefully no other bug reports for gnulib-tool.py since the info-gnu
> announcement other than the one I just patched is a good sign? :)
Yes, it's a good sign, and most probably a consequence of the testing
with various packages [1][2] that we did.
Bruno
I just pushed the two patches I sent previously.
Patch 0001 is the fix for missing libtests in testdirs.
Patch 0002 is the type hints for classes.
Hopefully no other bug reports for gnulib-tool.py since the info-gnu
announcement other than the one I just patched is a good sign? :)
CollinFrom
Hi Collin,
> This patch adds type hints to the Python classes.
Looks good. Thanks!
> Same as previously done in GLFileTable that I wrote. The only new
> thing introduced is the syntax for class variables, so this line in a
> class definition:
>
> section_label_pattern = re.compile(...)
>
gnulib/2024-04/msg00501.html
CollinFrom 613a0c35a7a03d1c716eba8ae98d5018f04a57f5 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Mon, 29 Apr 2024 03:25:32 -0700
Subject: [PATCH] gnulib-tool.py: Add type hints to classes.
* pygnulib/*.py: Add type hints for all instance and class variables.
* pygnulib/GLMakefileTable.py (GLMak
On 4/28/24 2:52 AM, Bruno Haible wrote:
> Thanks! OK to push in 1 or 2 days.
Sounds good.
>> Though, the correct way to fix this would be making instance variables
>> local when they are only used in one function.
>
> I agree that this kind of doing side effects on a GLConfig object that
> is al
Hi Collin,
> > The 'libtests' value read from the config in self.emitter is
> > incorrect.
>
> This patch seems to support what I was saying here.
>
> diff --git a/pygnulib/GLTestDir.py b/pygnulib/GLTestDir.py
> index 002eb30267..11b067e085 100644
> --- a/pygnulib/GLTestDir.py
> +++ b/pygnulib/G
Hi Bruno,
On 4/27/24 5:29 PM, Collin Funk wrote:
> I'm thinking that this is due to GLTestDir creating a GLEmiter in
> __init__() like this:
[...]
> The 'libtests' value read from the config in self.emitter is
> incorrect.
This patch seems to support what I was saying here.
diff --git a/pygnulib
On 4/27/24 4:06 PM, Bruno Haible wrote:
> The remaining problem now is:
>
> $ rm -rf ../testdir3; GNULIB_TOOL_IMPL=sh+py ./gnulib-tool
> --create-megatestdir --dir=../testdir3 --single-configure stdio
> sys_types
> ./gnulib-tool: *** gnulib-tool.py produced different fi
../testdir3; GNULIB_TOOL_IMPL=sh+py ./gnulib-tool --create-megatestdir
--dir=../testdir3 --single-configure stdio sys_types
./gnulib-tool: *** gnulib-tool.py produced different files than gnulib-tool.sh!
Compare ../testdir3 and ../testdir3-glpy3133646.
./gnulib-tool: *** Stop.
$ diff -r -q ../te
art of the problem was that a libtests was being
> generated. Putting the modules in a different order makes the libtests
> disappear?? What is going on?
Likewise. The sorting of gnulib-tool.py was still incorrect, so that
commit was needed minus my silly set mistake.
Sounds like it is time f
Hi Collin,
> I've pushed the attached patch
Thanks. There's a nit, though: These lines do not remove duplicates.
module_set = set(modules)
modules = [ module
for module in modules
if module in module_set ]
See:
>>> modules = ['a', 'b', 'a'
other (more reliable) subdirectories can at least be built and
> tested. Thus, sorting SUBDIRS in alphabetical order is generally unwelcome.
>
> It is gnulib-tool.py which needs to adapt.
Thanks for the explanation. I agree, I overlooked the purpose of
SUBDIRS in the original message.
I've
ign
>
> -SUBDIRS = sys_types stdio ALL
> +SUBDIRS = stdio sys_types ALL
Indeed, this part of the failure is a question of sorting.
> The behavior of gnulib-tool.py is to sort the modules and
> gnulib-tool.sh uses them as passed.
>
> I feel like the best solution here is just to s
configure.ac and the generated configure
script. The behavior of gnulib-tool.py is to sort the modules and
gnulib-tool.sh uses them as passed.
I feel like the best solution here is just to sort the modules in
gnulib-tool.sh. Since gnulib-tool.py turns the strings into a set of
GLModules and then
Hi Bruno,
On 4/27/24 8:48 AM, Bruno Haible wrote:
> Could you please look at this one? I created a megatestdir for some
> portability testing, with gnulib-tool.py (of course), and it failed
> on macOS:
Thanks for the report! I can reproduce it.
I have only had a brief look and it l
Hi Collin,
Could you please look at this one? I created a megatestdir for some
portability testing, with gnulib-tool.py (of course), and it failed
on macOS:
Making all in gltests
## ##
## --- Gnulib tests
implifying GLMakefileTable. I'll just
work on stuff in a local branch and maybe post them for review. Then
in 3 days *hopefully* there isn't any unexpected bugs in
gnulib-tool.py that need fixing.
> You are also free to make changes to the HACKING file (describing your IDE,
> for exampl
Hi Collin,
> Most of the instance variables in GLMegaTestDir are unused. This makes
> sense since GLMegaTestDir pretty much just calls GLTestDir functions
> on a list of modules and then does some extra work afterwards.
>
> I committed this patch removing them.
Looks good. Thanks.
However, plea
Sep 17 00:00:00 2001
From: Collin Funk
Date: Fri, 26 Apr 2024 01:58:09 -0700
Subject: [PATCH] gnulib-tool.py: Remove some unused instance variables.
* pygnulib/GLTestDir.py (GLMegaTestDir.__init__): Don't define instance
variables that are never used.
---
ChangeLog
Collin Funk wrote:
> for instance variables I
> rather put them outside __init__. It also serves as a decent place to
> add comments that don't belong in doc strings.
Yes. For instance variables that are used in several methods it would seem
odd to declare them in __init__. To me, __init__ is the
leTable when I was
looking at it previously. I imagine that section of code is probably
the most difficult for someone new to understand compared to the rest
of gnulib-tool.py.
Before I made the changes to GLModule.__hash__ the types were
something like this:
self.dependers: dict[str, list[s
Collin Funk wrote:
> I've applied the following patch adding a GLFileTable class as
> discussed here:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00357.html
Thanks! Looks good.
> +class GLFileTable:
> +'''The GLFileTable class stores file information for the duration of
ps.python.org/pep-0484/#type-comments
CollinFrom 962397de1dc64f44c5736be14efd9ffb95c93c65 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Wed, 24 Apr 2024 16:04:25 -0700
Subject: [PATCH] gnulib-tool.py: Add a new GLFileTable class.
* pygnulib/GLFileTable.py: New file. Define the GLFileTable c
Hi Bruno,
On 4/23/24 8:37 AM, Bruno Haible wrote:
> I also checked the effect on the warnings in Eclipse: No new warnings,
> and 1 existing "unused import" warning is fixed.
>
> The patch is OK to push.
Done. Thanks!
Collin
Hi Collin,
> > OK, patch welcome. I assume that when Dmitry used this style of assignments,
> > the Python 2.7 / 3.0 imports were not so well developed as they are today.
>
> Here is a patch that removes all the module-specific variables and
> imports the functions directly.
The patch looks good
too.
CollinFrom 96b746aca8cd77c121ffd4b4343e1b37aec1f745 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Mon, 22 Apr 2024 17:57:52 -0700
Subject: [PATCH] gnulib-tool.py: Make better use of imports.
* pygnulib/*.py: Import functions from constants.py directly instead of
assigning them to module-s
Hi Collin,
> I want to make the imports and use of functions from other modules
> consistent. This patch makes all files use absolute imports like
> main.py. So this:
>
>from pygnulib.GLEmiter import GLEmiter
>
> instead of:
>
>from .GLEmiter import GLEmiter
Consistency is not a good e
strange not too. :)
Any disagreement with those changes?
CollinFrom 740b31905915daa3bab5e7cfbd8347ea9f35ef3b Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sun, 21 Apr 2024 16:58:26 -0700
Subject: [PATCH] gnulib-tool.py: Use absolute imports consistently.
* pygnulib/*.py: Update imports.
---
ChangeLog
Collin Funk wrote:
> I am still learning about the
> type hinting and type checking stuff. Overall I think it is a good
> decision though. In the past I remember finding large Python code hard
> to follow without them.
Absolutely, yes.
Bruno
Hi Bruno,
On 4/21/24 2:43 PM, Bruno Haible wrote:
> Hmm. It's valid code that will work at runtime. I would understand a
> "warning", if the tool cannot prove that the code is safe. But "error"?
> That's too severe. It's again time for a bug report or two, I would say.
Haha, yes maybe "error" is
Hi Collin,
> > Also, what about the type of filetable? It is described as
> >
> > dict[str, list[str]]
> >
> > but I think it is more
> >
> > dict[str, list[str | tuple[str, str]]]
> >
> > right?
> ...
> Using union types like that is annoying with type checkers though. For
> example, usin
On 4/21/24 4:07 AM, Bruno Haible wrote:
> Also, what about the type of filetable? It is described as
>
> dict[str, list[str]]
>
> but I think it is more
>
> dict[str, list[str | tuple[str, str]]]
>
> right?
Good catch. I think the one you have written is correct because of the
filetable['o
Hi Bruno,
On 4/21/24 4:37 AM, Bruno Haible wrote:
> The former makes an implicit statement that the function is searching
> for the file. The latter does not; it does not say or hint to as what
> function internally does. Thus it is better to use the latter wording.
Agreed, thanks for the change
Collin Funk wrote:
> This patch prefixes temporary directories created by gnulib-tool.py
> with "glpy". gnulib-tool.sh uses the 'gl' prefix in func_tmpdir, and I
> suppose it is beneficial to differentiate the two.
Thanks, applied.
Bruno
1 - 100 of 686 matches
Mail list logo
