Gunicorn-22.0.0 egg file not building properly. Missing directories.

[ajayhb]

Gunicorn-22.0.0 egg file not building properly. Missing directories.

[ajayhb]

python-3.9

pip==22.0.4
setuptools==46.1.3
packaging==21.3

Sequence of commands might not be possible.

[pajod]

Please add the exact sequence of commands that lead you to that error, and the versions of pip, setuptools and packaging.

You typically do not need a setup.py file. If you cannot use existing wheels, you can still use our project metadata in pyproject.toml - build using python -m build.

If for some reason (probably involving deprecated toolchains) you absolutely must use setup.py then use the find_packages() shortcut, like this:

from setuptools import setup, find_packages
from gunicorn import __version__
setup(
    name='gunicorn', version=__version__,
    packages=find_packages(exclude=['examples', 'tests']),
    entry_points="[console_scripts]\ngunicorn=gunicorn.app.wsgiapp:run",
)

[ajayhb]

1. My services were running on gunicorn-21.1.0
2. I replaced all the occurrences of gunicorn-21.1.0 with gunicorn-22.0.0 in the codebase
3. Then in my submodule where I kept gunicorn-22.0.0 source code, I created a setup.py file to build it., which has the 3 line code mentioned above.
4. I associated the commit id of submodule in my main repo, where the services are using gunicorn.
5. On building my main source code (which in turn builds the source code of gunicorn via my setup.py), I get this error where the services are not starting.

[pajod]

builds the source code of gunicorn via my setup.py

Find out what other software in your deployment directly call setup.py - doing so for building or installing is deprecated and should usually instead let pip or build figure it out, e.g. python -m pip install . to install python -m build to build sdist+wheel

[ajayhb]

Bound to use setup.py for all the packages because of some dependencies. Will take sometime to move to pyproject.toml for building packages in my repo

[ajayhb]

Hi @pajod ,
I incorporated your changes of setup.py file and tried building the package from scratch.
However, I still do not see gunicorn/app/wsgiapp.py file inside the directory.

[root@makesh_FB222 /usr.src/contrib/python/var/python/lib/python3.9/site-packages/gunicorn-22.0.0-py3.9.egg]# ls
EGG-INFO        __init__.py     __main__.py     __pycache__     arbiter.py      config.py       debug.py        
errors.py       glogging.py     pidfile.py      reloader.py     sock.py         systemd.py      util.py

[pajod]

It works on my machine. If it is not the likely fully reproducible

sequence of commands that lead you to that error, or the versions of pip, setuptools and packaging

my next bet would be that it is ~𝖒𝖆𝖌𝖎𝖈~ but in that case I cannot help you, magic is illegal in my place.

[pajod]

I was able to install via my setup.py file from above using pip==22.0.4 setuptools==46.1.3 packaging==21.3 just fine.

I have suggested adding an equivalent setup.cfg file to our regular CI jobs to prove that this keeps working, for as long as Debian & Ubuntu releases shipping <v61 setuptools versions stick around: https://github.com/benoitc/gunicorn/pull/3134/files#diff-f159b002d021c363728aeff2c0d9cad2521c2cd553f77641481f2afb57ce7b73

[benoitc]

Maybe we should try to find a way to still ship a setup.py for those who need it? We should make sure the ux is goof. thoughts?

[pajod]

@benoitc Well how far to we want to go?

• a) avoid all breakage: entirely revert deleting setup.py, as using that file for configuration is likely going to remain supported for the foreseeable future and we have no pressing need to use the toml format for out packaging needs
• b) permit directly calling setup.py for some more time? a minimal stub would suffice.
  • this enables only the invocation, one would still need modern libraries - possibly nil overlap between these two
• c) permit using the build .whl files on old systems? ask tox CI to try the wheels
• d) permit people using older setuptools to build/install from source themselves? then either setup.cfg or setup.py needs to be restored, either
  1. duplicating a minimal set of metadata (as I did for my dpkg-buildpackage test) or
  2. completely giving up on all the things that the toml config is better at until truly nobody out there is unable to parse that format (Ubuntu 22.04 will receive extended support until April 2034)

I favour b+c+d1, and focus packaging-ux efforts on the toml:

• just delete unnecessary include-package-data and zip-safe
• likely also unnecessary license-files, namespaces and pytest-cov
• the import / path related stuff in tests is rather inflexible (and possibly the original justification for the zip-safe statement?)

[ajayhb]

Issue with freebsd machines on my setup. Have a workaround for now. Closing this.