Rok Mandeljc

Results 553 comments of Rok Mandeljc

Hmm, this actually looks like a bug in our `numpy` hook - it explicitly [excludes `numpy.distutils`](https://github.com/pyinstaller/pyinstaller/blob/e35a0a85e602b2ba0a4d7bb60043633dabe8b67c/PyInstaller/hooks/hook-numpy.py#L58) (which is why as an above work-around, its collection needs to be forced manually).

It's not `astropy`'s fault, though - at least not directly. It's [`numpy.ctypeslib.load_library` (that `astropy` uses to load its private extensions) that imports `numpy.distutils`](https://github.com/numpy/numpy/blob/75f852edf94a7293e7982ad516bee314d7187c2d/numpy/ctypeslib.py#L128). But I suppose using `numpy`'s convenience function...

Can you open the following file in your site-packages: `python3.7/site-packages/_pyinstaller_hooks_contrib/hooks/stdhooks/hook-tensorflow.py` find [the line that reads](https://github.com/pyinstaller/pyinstaller-hooks-contrib/blob/master/src/_pyinstaller_hooks_contrib/hooks/stdhooks/hook-tensorflow.py#L41): ``` excluded_submodules = ['tensorflow.python._pywrap_tensorflow_internal'] ``` and replace it with ``` excluded_submodules = [] ```

Hmm, you're right, but I can reproduce this only with UPX enabled. And it seems to work as expected if I exempt tcl/tk DLLs from UPX processing (`--upx-exclude tcl86t.dll --upx-exclude...

That's a definite "no" on the command-line parameter - I really don't want to fish for pyinstaller/bootloader-specific arguments from command-line arguments before passing them to your frozen python script But...

Well, the scenario I had in mind is actually that the PyInstaller-frozen application is started by a launcher script, where the environment variable could be set or not (or where...

This is caused by #7028 and collecting the `pywintypes3X.dll` into its original sub-directory. If each extension from site-`packages/win32` can be imported as its own top-level module, we'll need runtime hooks...

Can you open `build//Analysis-00.toc` file when building with 5.4.1 and when building 5.3, and check from where `python3.dll` was collected in each case?

Which python version are you actually using? And, are both python versions in `PATH`?

Hmmm, well, I think the most straightforward solution to the problem here would be to remove python 3.10 from the PATH; temporarily, in the environment that you are running PyInstaller...