Spyder.app fails with setuptools 61.0.0

[mrclary]

The latest release of setuptools 61.0.0 breaks the app bundle for Spyder .
See spyder-ide/spyder#17551.

Bundle creation works for setuptools 60.10.0

The observed symptoms are:

• The application bundle is named "spyder.app" rather than "Spyder.app". Not sure why the case is not respected...
• The application startup script is named "spyder.app/Contents/MacOS/spyder" rather than "Spyder.app/Contents/MacOS/Spyder". Again, not sure why the case is not respected...
• For the application bundle, the spyder source code should be included outside the zip (using the packages directive), however now it is included in the zip directory as well (two locations).

[ronaldoussoren]

Hmmm, that's weird.

While debugging another problem using a venv containing the Spyder dependencies I noticed that the resulting app contains a lot of code that shouldn't have been included, that might explain the last item on your list. I haven't debugged yet why this happens.

[ronaldoussoren]

The issue I mentioned earlier is likely unrelated, the problem there is that PIL by way of numpy pulls in a lot of dependencies when those are present. That's not a problem for Spyder because it actually uses those dependencies.

[ronaldoussoren]

I fixed a related issue in the repository, the Qt5 recipe resulted in a duplicate copy of parts of PyQ5 when using the wheel on PyPI.

I haven't checked yet how this fix affects Spyder.

[ronaldoussoren]

A workaround for the lowercase name of the app is to include a name argument in the call to setup(), that is:

        setup(name="Spyder", app=[app_script_path.as_posix()], options={'py2app': OPTIONS})

For some reason in setuptools 61.0 the distutils.dist.Distribution name gets set to a value, even though the setup.py file does not contain a name. Setuptools 60.0 works as expected by py2app. Because of this change the default calculation of the app name based on the name of the script never kicks in, resulting in an incorrect name.

This is an explicit change in setuptools: pypa/setuptools#2894, which is one of the changes in setuptools 61.0.

This is something I cannot work around in py2app, by the time my code gets run the damage is already done.

A workaround for this: add an empty py_modules argument to the call to setup: setup(py_modules=[], ...). This will disable the autodiscovery code in setuptools (for now).

[mrclary]

I'll give those a try and report back.

[ronaldoussoren]

I've filed pypa/setuptools#3248 about the auto discovery problem.

[mrclary]

Using name= and py_modules= worked as you suggested for setuptools>60.10.0 including 62.0.0.

[ronaldoussoren]

The next release of py2app should work out of the box with these versions of setuptools.

[ronaldoussoren]

@mrclary Is the problem with duplication of code in the generated app bundle still present?

[mrclary]

I'll verify, standby...

[ronaldoussoren]

On my machine the app bundle looks correct, no duplicate spider.

BTW. The Readme.md in installers/macOS appears to be out of date. The instruction for installing dependencies contains:

pip install -r req-build.txt -r req-extras.txt -c req-const.txt -e ../../

req-const.txt is not in the repository, but there are two other requirement files that appear to be required.

[mrclary]

Looks good on my local machine as well. It works even without py_modules specified.

BTW. The Readme.md in installers/macOS appears to be out of date

Indeed. Thanks for reminding me 😄 .

[ronaldoussoren]

Great. I'll push out a new release over the weekend.

Specifying py_modules or name should no longer be necessary, I'm using a setuptools entrypoint to do this automatically.