pypa / setuptools

Official project repository for the Setuptools build system
https://pypi.org/project/setuptools/
MIT License
2.36k stars 1.15k forks source link

setuptools 45.0.0 may cause PyInstaller 3.3 packaged executable fail to launch #1963

Closed frederickfung closed 4 years ago

frederickfung commented 4 years ago

In my specific example where we use PyInstaller 3.3 to package our application into an executable for deployment, the resulting executable cannot be launched after setuptools was updated from 44.0.0 to 45.0.0. This happened right at 9:00PM Pacific Time yesterday.

The error signature is (when launching the executable generated by PyInstaller):

[1072] Failed to execute script pyi_rth_pkgres
Traceback (most recent call last):
  File "site-packages/PyInstaller/loader/rthooks/pyi_rth_pkgres.py", line 11, in <module>
  File "/<virtualenv-path>/lib/python3.6/site-packages/PyInstaller/loader/pyimod03_importers.py", line 631, in exec_module
    exec(bytecode, module.__dict__)
  File "site-packages/pkg_resources/__init__.py", line 86, in <module>
ModuleNotFoundError: No module named 'pkg_resources.py2_warn'

PyInstaller version is 3.3, setuptools is 45.0.0 Working just fine with setuptools 44.0.0

For certain limitations in our Python application, we are stuck with Pyinstaller 3.3, but we are definitely looking into using later versions of PyInstaller.

yoctozepto commented 4 years ago

And virtualenv is broken: https://github.com/pypa/virtualenv/issues/1493

It seems the impact is wider than imagined.

pganssle commented 4 years ago

Hm, maybe I'm wrong here, but I'm not sure why this particular failure mode would happen. Presumably if setuptools==45.0.0 is installed, it should have a pkg_resources.py2_warn, and if it's not installed, there should be no references to that module in the code. Is there some sort of cross-compile happening? Can you provide a minimal working example?

Also, you mention trying different versions of setuptools, but have you tried the latest version of PyInstaller? Whether or not you can use it yourself, it would be good to know whether this will also break with the latest version of PyInstaller.

tardyp commented 4 years ago

FWIW, I got this error also on the buildbot CI.

it happen that I had pip pinned to < 19 because of https://github.com/pypa/pip/issues/6163 (which has ben fixed since), but pyinstaller was latest

pinning setuptools < 45 fixes the issue as per https://github.com/buildbot/buildbot/pull/5059/commits/1ab091604dae8ec8fd7479e6fac6158280029963

unpinning everything keeps the error. https://github.com/buildbot/buildbot/pull/5059/commits/340bcf317e4a8ecd35396bc4d0e91642531e4f43

[1337] Failed to execute script pyi_rth_pkgres
Traceback (most recent call last):
  File "PyInstaller/loader/rthooks/pyi_rth_pkgres.py", line 11, in <module>
  File "/home/buildbot/repo/.venv/lib/python3.5/site-packages/PyInstaller/loader/pyimod03_importers.py", line 627, in exec_module
    exec(bytecode, module.__dict__)
  File "pkg_resources/__init__.py", line 86, in <module>
ImportError: No module named 'pkg_resources.py2_warn'
dploeger commented 4 years ago

On another note, the Puppet package provider for pip packages also has problems with this warning. IMO it should have the option to disable the warning.

Cory-Kramer commented 4 years ago

We ran into the same issue this morning, using PyInstaller 3.6

priitlatt commented 4 years ago

Observed the same behaviour on Python 3.7.5 with PyInstaller 3.5 and PyInstaller 3.6. I was able to build again successfully after reverting to previous release of setuptools:

pip install --upgrade 'setuptools<45.0.0'
christianbioinf commented 4 years ago

I am having the same issue with Python 3.6.8 and Pyinstaller 3.6. I suspect that it is caused by the recent commit pypa/setuptools@79f1694b05a66cc0fbbbf4e72d63d0a340cf6d84 in setuptools since it added the line __import__('pkg_resources.py2_warn') but not a regular import line like import pkg_resources.py2_warn (as done for other __import__ statements in pkg_resources.__init__.py) and afaik Pyinstaller does not scan for __import__ statements and hence does not freeze the file pkg_resources.py2_warn.py.

gsemet commented 4 years ago

Fixed by forcing in a hook file the following submodule collection:

...
hiddenimports.extend(collect_submodules('pkg_resources'))
ifalex commented 4 years ago

Shall we get a new update today or what is the plan?

wedesoft commented 4 years ago

Fixed by adding a hidden import:

a = Analysis(...,
             hiddenimports=['pkg_resources.py2_warn'],
             ...)
jaraco commented 4 years ago

It looks to me like Pyinstaller has a fix for this issue. I would simply update the import to be from . import py2_warn, but that adds an unwanted name to the namespace.

Is it possible for setuptools to provide a hook that would enable older versions of pyinstaller to work with newer versions of setuptools? How is that done?

calebwoofenden commented 4 years ago

@jaraco what fix does Pyinstaller have for this?

jaraco commented 4 years ago

I was mistaken. I misread the references above and thought they were applied to Pyinstaller.

jaraco commented 4 years ago

How is it that other similar imports in pkg_resources aren't a problem for pyinstaller?

Is it possible for setuptools to provide a hook that would enable pyinstaller to work with newer versions of setuptools? How is that done?

Here's how keyring adds a hook for hidden imports.

Could someone with Pyinstaller expertise make a recommendation on what's the recommended approach here?

gsemet commented 4 years ago

Fixed by forcing in a hook file the following submodule collection:

...
hiddenimports.extend(collect_submodules('pkg_resources'))

My hack works whatever the version of setuptools. I’ll see if I have time to do a clean PR in here.

rkeerdo93 commented 4 years ago

Can also confirm this happens with later versions of PyInstaller (3.6) Traceback (most recent call last): File "PyInstaller/loader/rthooks/pyi_rth_pkgres.py", line 13, in <module> File "/root/.local/share/virtualenvs/HIDDEN-2XAjamty/lib/python3.6/site-packages/PyInstaller/loader/pyimod03_importers.py", line 623, in exec_module File "pkg_resources/__init__.py", line 86, in <module> ModuleNotFoundError: No module named 'pkg_resources.py2_warn' [24514] Failed to execute script pyi_rth_pkgres

ifalex commented 4 years ago

If you're using pyinstaller from bash you can use "--hidden-import='pkg_resources.py2_warn'" to get rid of this issue. Eg: pyinstaller --hidden-import='pkg_resources.py2_warn' ${package}

jaraco commented 4 years ago

In the commit (79f1694b05a66cc0fbbbf4e72d63d0a340cf6d84), a comment was made that this affects cxFreeze also.

The suggestion was made to simply use import to import the module, such as is done with py31compat. For py2warn, I chose to use __import__ to signal that the side effect is what's desired (and to avoid linter warnings about an unused bound name, F401 imported but unused). With py31compat, the name is used later in the module; that's not the case with py2warn.

As you can see, adjacent to this import, there are very similar import calls in this module that do not import any other names and there's no comment or other tests preventing this sort of usage. I don't understand why this import is causing trouble while others are not.

Probably tools like cxFreeze and pyInstaller should honor __import__ calls, especially when they're at the top of an imported module. I don't know why they're not.

Even better, these tools should probably consider not relying primarily on runtime inference for module detection but instead rely on package metadata like importlib.metadata and Python Packaging tools like pip or pep517 to assemble these packages more deterministically.

Failing that, these tools should provide a mechanism for a project such as setuptools to advertise its "hidden" imports.

I'm sad to see there are so many workarounds for this issue but no robust solution. I'm happy to work with the maintainers of cxFreeze or PyInstaller to develop a robust solution.

Without a better recommendation, this behavior is working as intended, so I'm closing the ticket, but happy to re-open if there's an actionable recommendation.

matham commented 4 years ago

Failing that, these tools should provide a mechanism for a project such as setuptools to advertise its "hidden" imports.

The pyinstaller mechanism is to use hooks that describe the hidden imports for each package. Looking at their hooks, it seems it should already be fixed in their master?

https://github.com/pyinstaller/pyinstaller/blob/develop/PyInstaller/hooks/hook-setuptools.py https://github.com/pyinstaller/pyinstaller/blob/develop/PyInstaller/hooks/hook-pkg_resources.py

jaraco commented 4 years ago

Oh, that's great. Thanks for the reference. It's too bad that change requires pyinstaller to keep up with any project a user might want to use, but at least there's a supported mechanism. If there were a way to declare that in Setuptools to improve compatibility with older pyinstallers, I'd be open to that improvement.

jpeg13 commented 4 years ago

The suggestion was made to simply use import to import the module, such as is done with py31compat. For py2warn, I chose to use __import__ to signal that the side effect is what's desired (and to avoid linter warnings about an unused bound name, F401 imported but unused). With py31compat, the name is used later in the module; that's not the case with py2warn.

As far as I understand (and this is not much), you could have reached the same effect with

import pkg_resources.py2_warn
del pkg_resources.py2_warn

This would at least have avoided the issue for cx_Freeze (beside being explicit). Anyhow, even if this would be an acceptable recommendation for you, it is "too late" in the sense that cx_Freeze probably needs to be patched to work with setuptools 45.0.0 anyway (see below).

As you can see, adjacent to this import, there are very similar import calls in this module that do not import any other names and there's no comment or other tests preventing this sort of usage. I don't understand why this import is causing trouble while others are not.

At least in cx_Freeze, there was already a hook for the other similar imports.

Failing that, these tools should provide a mechanism for a project such as setuptools to advertise its "hidden" imports.

The cx_Freeze mechanism is also to provide hooks to advertise the "hidden" import. I've opened a corresponding issue https://github.com/anthony-tuininga/cx_Freeze/issues/579 and made a PR proposal there.

bribrah commented 4 years ago

Why is this closed if its still an issue?

Safihre commented 4 years ago

@bribrah they patched it in PyInstaller (see comment above) so should work in the next release of PyInstaller.

jaraco commented 4 years ago

To be sure, Setuptools could adopt workarounds here, such as

but these approaches are ugly, thus are likely to be cleaned up in a future commit, and suggest that no python module should ever use __import__ or importlib.import_module. This latter aspect is the most important. I don't want to "fix" the issue here only to accept the burden of maintaining that fix across all projects. I'd really only feel comfortable with this approach if the docs for __import__ and importlib.import_module both had warnings stating not to use them as they break these use cases.

Even more importantly, this issue is only one manifestation of the underlying problem, that these installers are attempting to infer the modules/files for a package by inspecting the code, code which is known to have dynamic behaviors around imports. Another example where this issue has arisen is with packages that use "entry points" for inversion of control and where importing a module hosting the entry point happens programmatically. No amount of syntax hacks is going to help with that situation. Whatever these bundler tools use should also address that concern and through the same mechanism.

At this point, until there's a more sophisticated mechanism for a bundler to discover the files in use, the workaround already employed is the least worst approach. Going forward, package developers should feel free to use the constructs of the language and these bundling tools will need to react whenever a construct like this is employed.

Is there a forum where maintainers of PyInstaller and cxFreeze (and others) convene to discuss designs around the common challenges of these tools? I have some ideas I'd be happy to share.

matham commented 4 years ago

Is there a forum where maintainers of PyInstaller and cxFreeze (and others) convene to discuss designs around the common challenges of these tools? I have some ideas I'd be happy to share.

I'm not aware of any such thing and would guess that these designs just arose organically. I have also reflected that this puts all the work on the pyinstaller devs because you have to update the hooks in the pyinstaller repo, as opposed to updating them directly in each package according to some specified syntax as the package changes. And yeah, it misses imports that are not "standard". It would be nice if there was a way for package maintainers to declare the various files that may need to be included in a app.

Maybe Python's discourse would be a good place to bring up these ideas? I know pyinstaller is already struggling with maintainer time, so they may not be in a position to implement these ideas, but someone interested could?

But FYI, there is more complexity here than you may be considering. Bundling a fully functioning app should typically mean that you bundle the minimum modules required to run a package given the way the package is used by the app. E.g. consider a framework that provides some core modules, audio/video, and some other modules. Each of these modules depend on some external packages. E.g. audio/video may require a 100MB gstreamer package. Currently, pyinstaller should be able to tell which framework modules you use in the app and only bundle gstreamer if you actually use the audio/video module. I'm not sure pip style metadata would be able to do this?

tammy4626 commented 4 years ago

我也遇到同樣的問題 對虛擬的環境重新更新pip 在C:\virenv\Scripts\ 目錄下 pip install --upgrade setuptools==44.0.0 就解決了

lrq3000 commented 4 years ago

Still an issue, got bitten by it with the latest Miniconda3. Fixed it on Windows by typing:

pyinstaller -F -c --hidden-import="pkg_resources.py2_warn" your_script.py

Note the use of double quotes, as single quotes do not work here on Windows.

jaraco commented 4 years ago

consider a framework that provides some core modules, audio/video, and some other modules. Each of these modules depend on some external packages. E.g. audio/video may require a 100MB gstreamer package.

In cases like these, I think the framework should request from the upstream gstreamer package to release compartmentalized modules for selective functionality, such as through extras or sub-packages, such that pyinstaller could rely entirely on a curated requirements.txt and constraints.txt to specify exactly which packages to include and exclude and through that mechanism effectively limit unused, bulky packages (but otherwise include all the functionality). In other words, let's use the features of the packaging ecosystem to build a packaging landscape that suits all the use-cases (including bundlers).

For example, if the functionality required from gstreamer is only one module, that module should be extracted to a separate library gstreamer-featureX, on which gstreamer depends and which other libraries could rely instead of gstreamer.

An example where I used this approach, an application was relying on the "port checking" functionality of cherrypy, but it seemed awkward and risky to pull in an entire HTTP server just to check some TCP ports, so I extracted portend as a separate package on which cherrypy now depends. Now projects that only needed the port checking functionality could get that independently and with a tiny library. I took a similar approach with jaraco.util, which I broke into a dozen or so function-oriented libraries.

Of course, maintaining multiple packages can be a challenge, which is why I've developed a maximally lightweight process for managing packages.

Manuelraa commented 4 years ago

So I got the same error. Different setup. Fix was just to add the import into my script. Hope this helps someone if he googles for the same error. import pkg_resources.py2_warn

Manuelraa commented 4 years ago

Still an issue, got bitten by it with the latest Miniconda3. Fixed it on Windows by typing:

pyinstaller -F -c --hidden-import="pkg_resources.py2_warn" your_script.py

Note the use of double quotes, as single quotes do not work here on Windows.

I guess that's a better solution I didn't see

alokparna-wsu commented 4 years ago
hiddenimports.extend(collect_submodules('pkg_resources'))

Hi.. can you please tell me where should I put this line of code? I am trying to convert a Django project to exe file and when executing the exe file from console, I am getting the same error.

(django_env)C:\Users\abandyop\Desktop\AKTOS\BarcodeScanProject\Barcode_Django\dist\Barcode_Django>Barcode_Django.exe runserver localhost:8000

Traceback (most recent call last):
  File "site-packages\PyInstaller\loader\rthooks\pyi_rth_pkgres.py", line 13, in <module>
  File "c:\users\abandyop\.conda\envs\django_env\lib\site-packages\PyInstaller\loader\pyimod03_importers.py", line 623, in exec_module
    exec(bytecode, module.__dict__)
  File "site-packages\pkg_resources\__init__.py", line 86, in <module>
ModuleNotFoundError: No module named 'pkg_resources.py2_warn'
[15468] Failed to execute script pyi_rth_pkgres
Safihre commented 4 years ago

You either add this to your .spec-file if you use it before the Analysis step, or add it as a command-line parameter --hidden-import="pkg_resources.py2_warn"

premananda8 commented 4 years ago

my observation pyinstaller version=3.5 and setuptool 41.2.0 working correctly pynstaller.

truekonrads commented 3 years ago

I still have this issue:

$py -mpip show setuptools
Name: setuptools
Version: 47.3.1
Summary: Easily download, build, install, upgrade, and uninstall Python packages
Home-page: https://github.com/pypa/setuptools
Author: Python Packaging Authority
Author-email: distutils-sig@python.org
License: UNKNOWN
Location: c:\python38-32\lib\site-packages
Requires:
Required-by: xmldiff, PyInstaller, jsonschema, ipython

$ py -mpip show PyInstaller
Name: PyInstaller
Version: 3.6
Summary: PyInstaller bundles a Python application and all its dependencies into a single package.
Home-page: http://www.pyinstaller.org
Author: Giovanni Bajo, Hartmut Goebel, David Vierra, David Cortesi, Martin Zibricky
Author-email: pyinstaller@googlegroups.com
License: GPL license with a special exception which allows to use PyInstaller to build and distribute non-free programs (including commercial ones)
Location: c:\python38-32\lib\site-packages
Requires: pefile, altgraph, pywin32-ctypes, setuptools
Required-by:

Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32 bit (Intel)] on win32
Salim9304 commented 3 years ago

Python 3.7.8 Jun 28 2020, 08:53:46) [MSC v.1916 64 bit (AMD64)] on win32 I updated my python from 3.7.7 (32bit) to 3.7.8 (64bit). I started to get this mistake:

File "site-packages\pkg_resources__init__.py", line 86, in ModuleNotFoundError: No module named 'pkg_resources.py2_warn' [4188] Failed to execute script pyi_rth_pkgres

I was helped by a comment from the branch above: https://github.com/pypa/setuptools/issues/1963#issuecomment-574265532

NoiseControllers commented 3 years ago

Same mistake in python 3.8.2 and 49.1.0 setuptools.

This solved the problem. https://github.com/pypa/setuptools/issues/1963#issuecomment-574265532

jaraco commented 3 years ago

Also note that with #2238, the next release of Setuptools (49.1.1 or later) will no longer be subject to the issue.

jaraco commented 3 years ago

Just occurred to me - why wait. So 49.1.1 is going out for release now.

anchalsingh298358 commented 3 years ago

I am getting his error while trying to convert my project exe file directroy with Auto-py-to-exe

Running auto-py-to-exe v2.9.0

Building directory: C:\Users\Dell\AppData\Local\Temp\tmpan03u43h

Provided command: pyinstaller --noconfirm --onedir --console --add-data "E:/Projects in Python/Drowsiness detection/alarm.wav;." --add-data "E:/Projects in Python/Drowsiness detection/model.py;." --add-data "E:/Projects in Python/Drowsiness detection/tkinter event.py;." --add-data "E:/Projects in Python/Drowsiness detection/models;models/" --add-data "E:/Projects in Python/Drowsiness detection/haar cascade files;haar cascade files/" "E:/Projects in Python/Drowsiness detection/drowsiness detection.py"

Recursion Limit is set to 5000

Executing: pyinstaller --noconfirm --onedir --console --add-data E:/Projects in Python/Drowsiness detection/alarm.wav;. --add-data E:/Projects in Python/Drowsiness detection/model.py;. --add-data E:/Projects in Python/Drowsiness detection/tkinter event.py;. --add-data E:/Projects in Python/Drowsiness detection/models;models/ --add-data E:/Projects in Python/Drowsiness detection/haar cascade files;haar cascade files/ E:/Projects in Python/Drowsiness detection/drowsiness detection.py --distpath C:\Users\Dell\AppData\Local\Temp\tmpan03u43h\application --workpath C:\Users\Dell\AppData\Local\Temp\tmpan03u43h\build --specpath C:\Users\Dell\AppData\Local\Temp\tmpan03u43h

736467 INFO: PyInstaller: 4.3

736489 INFO: Python: 3.6.8rc1

736498 INFO: Platform: Windows-10-10.0.19041-SP0

736520 INFO: wrote C:\Users\Dell\AppData\Local\Temp\tmpan03u43h\drowsiness detection.spec

736653 INFO: UPX is not available.

736783 INFO: Extending PYTHONPATH with paths ['E:\Projects in Python\Drowsiness detection', 'C:\Users\Dell\AppData\Local\Temp\tmpan03u43h']

744094 INFO: checking Analysis

744123 INFO: Building Analysis because Analysis-00.toc is non existent

744152 INFO: Initializing module dependency graph...

744198 INFO: Caching module graph hooks...

744302 WARNING: Several hooks defined for module 'win32ctypes.core'. Please take care they do not conflict.

744620 INFO: Analyzing base_library.zip ...

763780 INFO: Caching module dependency graph...

764287 INFO: running Analysis Analysis-00.toc

764398 INFO: Adding Microsoft.Windows.Common-Controls to dependent assemblies of final executable required by c:\users\dell\appdata\local\programs\python\python36\python.exe

764756 INFO: Analyzing E:\Projects in Python\Drowsiness detection\drowsiness detection.py

766483 INFO: Processing pre-find module path hook distutils from 'c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\hooks\pre_find_module_path\hook-distutils.py'.

766558 INFO: distutils: retargeting to non-venv dir 'c:\users\dell\appdata\local\programs\python\python36\lib'

766839 INFO: Processing pre-find module path hook site from 'c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\hooks\pre_find_module_path\hook-site.py'.

766861 INFO: site: retargeting to fake-dir 'c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\fake-modules'

769115 INFO: Processing pre-safe import module hook six.moves from 'c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\hooks\pre_safe_import_module\hook-six.moves.py'.

893728 INFO: Processing pre-safe import module hook urllib3.packages.six.moves from 'c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\hooks\pre_safe_import_module\hook-urllib3.packages.six.moves.py'.

1408036 INFO: Processing module hooks...

1408057 INFO: Loading module hook 'hook-certifi.py' from 'c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\_pyinstaller_hooks_contrib\hooks\stdhooks'...

1408204 INFO: Loading module hook 'hook-cryptography.py' from 'c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\_pyinstaller_hooks_contrib\hooks\stdhooks'...

An error occurred while packaging Traceback (most recent call last): File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\auto_py_to_exe\packaging.py", line 131, in package run_pyinstaller() File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller__main.py", line 114, in run run_build(pyi_config, spec_file, vars(args)) File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller__main__.py", line 65, in run_build PyInstaller.building.build_main.main(pyi_config, spec_file, kwargs) File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\building\build_main.py", line 737, in main build(specfile, kw.get('distpath'), kw.get('workpath'), kw.get('clean_build')) File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\building\build_main.py", line 684, in build exec(code, spec_namespace) File "C:\Users\Dell\AppData\Local\Temp\tmpan03u43h\drowsiness detection.spec", line 18, in noarchive=False) File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\building\build_main.py", line 242, in init self.postinit() File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\building\datastruct.py", line 160, in postinit self.assemble() File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\building\build_main.py", line 420, in assemble self.graph.process_post_graph_hooks() File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\depend\analysis.py", line 367, in process_post_graph_hooks module_hook.post_graph() File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\depend\imphook.py", line 447, in post_graph self._load_hook_module() File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\depend\imphook.py", line 409, in _load_hook_module self.hook_module_name, self.hook_filename) File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\compat.py", line 605, in importlib_load_source return mod_loader.load_module() File "", line 399, in _check_name_wrapper File "", line 823, in load_module File "", line 682, in load_module File "", line 265, in _load_module_shim File "", line 684, in _load File "", line 665, in _load_unlocked File "", line 678, in exec_module File "", line 219, in _call_with_frames_removed File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages_pyinstaller_hooks_contrib\hooks\stdhooks\hook-cryptography.py", line 26, in datas = copy_metadata('cryptography') File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\PyInstaller\utils\hooks__init.py", line 944, in copy_metadata dist = pkg_resources.get_distribution(package_name) File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\pkg_resources__init__.py", line 466, in get_distribution dist = get_provider(dist) File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\pkg_resources\init__.py", line 342, in get_provider return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0] File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\pkg_resources\init.py", line 886, in require needed = self.resolve(parse_requirements(requirements)) File "c:\users\dell\appdata\local\programs\python\python36\lib\site-packages\pkg_resources\init__.py", line 772, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'cryptography' distribution was not found and is required by the application

Project output will not be moved to output folder

Complete.