Recursion error with Pydantic #5131
Comments
|
This may be caused by pydantic having two files for the same module with the same base name. I'm investigating. |
|
Here's when things start going wrong: |
Closed
|
Looks like this is a duplicate of #4346. |
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Sep 10, 2020
These tests check for "recursion too deep" caused by the `__init__` module being an extension module. See pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Sep 10, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see pyinstaller#5131, pyinstaller#4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change `_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See pyinstaller#4406, closes pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Sep 10, 2020
These tests check for "recursion too deep" caused by the `__init__` module being an extension module. See pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Sep 10, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see pyinstaller#5131, pyinstaller#4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change ``_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See pyinstaller#4406, closes pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Sep 10, 2020
These tests check for "recursion too deep" caused by the `__init__` module being an extension module. See pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Sep 10, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see pyinstaller#5131, pyinstaller#4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change ``_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See pyinstaller#4406, closes pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Sep 10, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see pyinstaller#5131, pyinstaller#4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change ``_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See pyinstaller#4406, closes pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Sep 12, 2020
These tests check for "recursion too deep" caused by the `__init__` module being an extension module. See pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Sep 12, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see pyinstaller#5131, pyinstaller#4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change ``_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See pyinstaller#4406, closes pyinstaller#5131, pyinstaller#4346.
phil65
pushed a commit
to phil65/pyinstaller
that referenced
this issue
Oct 1, 2020
These tests check for "recursion too deep" caused by the `__init__` module being an extension module. See pyinstaller#5131, pyinstaller#4346.
phil65
pushed a commit
to phil65/pyinstaller
that referenced
this issue
Oct 1, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see pyinstaller#5131, pyinstaller#4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change ``_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See pyinstaller#4406, closes pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Oct 11, 2020
These tests check for "recursion too deep" caused by the `__init__` module being an extension module. See pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Oct 11, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see pyinstaller#5131, pyinstaller#4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change ``_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See pyinstaller#4406, closes pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Oct 18, 2020
These tests check for "recursion too deep" caused by the `__init__` module being an extension module. See pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Oct 18, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see pyinstaller#5131, pyinstaller#4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change ``_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See pyinstaller#4406, closes pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
to htgoebel/pyinstaller
that referenced
this issue
Oct 18, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see pyinstaller#5131, pyinstaller#4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change ``_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See pyinstaller#4406, closes pyinstaller#5131, pyinstaller#4346.
htgoebel
added a commit
that referenced
this issue
Oct 18, 2020
modulegraph's heritage includes code still based on Python 2.x capabilities on how to find a module and get its source or code. It also contained a anomaly regarding packages and their ``__init__``-file: If a package was detected, it's ``__init__`` file was loaded as a module. This, while being ugly, worked in most cases, but failed if the ``__init__`` module is an extension module (see #5131, #4346), ending in an infinite loop. This was caused by modulegraph distinguishing between the package and its ``__init__`` module. The solution is to switch to "modern" loaders, both being a loader for a specific type of modules (source, extension, etc.) and having a package characteristic (property ``is_package()``) This commit does the following - In ``_find_module_path()`` no longer return "metadata" but a loader. This also removed huge part of this function, making it much easier to understand. As a side effect, this asymmetric closing of a file in a completely other part of the code (``_safe_import_module``) could be removed. - Change ``_load_module`` to use the loaders. - Merge ``_load_package`` into `__load_module``, getting rid of the anomaly described above. - Adjust the test-cases to the new behavior (esp. loader instead of metadata-tuple and filehandle) Please note: Since we plan to change to modulegraph2 soon anyway, I did not spend too much time on creating a clean solution. See #4406, closes #5131, #4346.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
+++ ONLY TEXT +++ DO NOT POST IMAGES +++
Description of the issue
Trying to run pyinstaller against a module that contains just
import pydanticfails due toRecursionError: maximum recursion depth exceeded while calling a Python object.Context information (for bug reports)
Output of
pyinstaller --version:4.0Version of Python: 3.8
Platform: Fedora 32
Did you also try this on another platform? Does it work there? I didn't
try the latest development version, using the following command:
(https://github.com/pyinstaller/pyinstaller/wiki/If-Things-Go-Wrong) and
Make sure everything is packaged correctly
--noupxor setupx=Falsein your .spec-file--debugtopyi-makespecorpyinstalleror useEXE(..., debug=1, ...)in your .spec file.A minimal example program which shows the error
Stacktrace / full error message
Please also see https://github.com/pyinstaller/pyinstaller/wiki/How-to-Report-Bugs
for more about what would use to solve the issue.
The text was updated successfully, but these errors were encountered: