Building a Distributable with Custom Panda

So, I’m trying to create a distributable version of a game that I’m working on. Under normal conditions, this should be straightforward via setuptools.

However, I have a modified version of VFSImporter.py–one that is, I think, reflected in the “master” branch but not in the “1.10” branch that I’m using.

To this end, I’m attempting to make a custom build of the engine, and to then create a build of my game with that engine-build.

So far I’ve created the custom Panda build, and have specifically created it as a “whl”-file.

(Yes, I know, I’m reinventing the whl! :P)

The problem at this point, then, is getting setuptools, etc. to accept that engine-build.

For now, for ease of use (as I’m not familiar with the details of the requirements.txt format) I’ve simply copied the new wheel into the directory from which I’m making the game-build.

With that done, I have the following “requirements.txt” file:

./panda3d-1.10.16-cp312-cp312-linux_x86_64.whl
panda3d

However, when I attempt to build, I get the following output:

setup.py bdist_apps
running bdist_apps
running build_apps
Building platforms: manylinux2014_x86_64
Gathering wheels for platform: manylinux2014_x86_64
Looking in indexes: https://pypi.org/simple, https://archive.panda3d.org/simple/opt, https://archive.panda3d.org/thirdparty
ERROR: panda3d-1.10.16-cp312-cp312-linux_x86_64.whl is not a supported wheel on this platform.

Followed by a long traceback, as follows:

Traceback (most recent call last):
  File "/home/thaumaturge/Documents/My Game Projects/MoonsInCrystal/setup.py", line 12, in <module>
    setup(
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/setuptools/__init__.py", line 115, in setup
    return distutils.core.setup(**attrs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/setuptools/_distutils/core.py", line 186, in setup
    return run_commands(dist)
           ^^^^^^^^^^^^^^^^^^
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/setuptools/_distutils/core.py", line 202, in run_commands
    dist.run_commands()
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/setuptools/_distutils/dist.py", line 1002, in run_commands
    self.run_command(cmd)
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/setuptools/dist.py", line 1102, in run_command
    super().run_command(command)
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/setuptools/_distutils/dist.py", line 1021, in run_command
    cmd_obj.run()
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/direct/dist/commands.py", line 1772, in run
    self.run_command('build_apps')
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/setuptools/_distutils/cmd.py", line 357, in run_command
    self.distribution.run_command(command)
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/setuptools/dist.py", line 1102, in run_command
    super().run_command(command)
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/setuptools/_distutils/dist.py", line 1021, in run_command
    cmd_obj.run()
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/direct/dist/commands.py", line 524, in run
    self.build_runtimes(platform, True)
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/direct/dist/commands.py", line 718, in build_runtimes
    wheelpaths = self.download_wheels(platform)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/site-packages/direct/dist/commands.py", line 590, in download_wheels
    subprocess.check_call([sys.executable, '-m', 'pip'] + pip_args)
  File "/home/thaumaturge/.pyenv/versions/3.12.8/lib/python3.12/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/home/thaumaturge/.pyenv/versions/3.12.8/bin/python3', '-m', 'pip', '--disable-pip-version-check', 'download', '-d', '/home/thaumaturge/Documents/My Game Projects/MoonsInCrystal/build/__whl_cache__/manylinux2014_x86_64_cp312', '-r', '/home/thaumaturge/Documents/My Game Projects/MoonsInCrystal/requirements.txt', '--only-binary', ':all:', '--abi', 'cp312', '--platform', 'manylinux2014_x86_64', '--extra-index-url', 'https://archive.panda3d.org/simple/opt', '--extra-index-url', 'https://archive.panda3d.org/thirdparty']' returned non-zero exit status 1.

Does anyone know what I’m doing wrong…?

Two days ago, I built Panda3D 1.10.16 on Windows as a wheel, but I couldn’t install it in Python due to platform incompatibilities. I think the build system doesn’t have a problem.

You built your wheel for your local version of your Linux distribution. Your wheel will probably only work on that specific Linux distribution, or at least those that pack at least the versions of the library shipped there.

What we do is build for “manylinux2014”, which is a special, old version of Linux that is known to be compatible with a broad range of Linux versions released in the past 10 years. It receives a special “manylinux2014” tag, which is more specific than the “linux” tag of your built wheel.

If you want to build with manylinux2014, you can do that by installing Docker and using the manylinux2014 image on that, and building Panda3D in that.

Alternatively, you can use your linux wheels, but you would need to adjust your setup.py file to build “linux” wheels and not “manylinux”. Specifically, change platforms to say ["linux_x86_64"] and it will use your wheel.

I’m not sure if the line in requirements.txt directly naming the .whl file is right; it may well be, but then the second line (“panda3d”) is probably unnecessary. Alternatively, just specify the path to the directory containing the wheels with -f directory/to/wheels and leave panda3d on a line after that.

I recall seeing that thread, yes. Although, from rdb’s response, it sounds like the problem here is on my end, not that of the build system.

Ah. That’s troublesome–and likely won’t work for me.

Further, I realised this morning that what I’ve built won’t give me Windows builds, either, I imagine–which is again a problem. :/

(I want to make this build for the purpose of pitching, which means I won’t know on what Windows or Linux systems it’ll be run.)

Hmm… I’d really rather not start messing around with that, especially for what I imagine is a transitory problem: once 1.11 is released, it should come with the updated VFSImporter script, allowing me to use the standard build process again, I daresay.

Plus, using Docker would still (presumably) leave me with the Windows problem…

I’m thinking now that perhaps I should instead address this problem by installing Python 3.11 (if I recall the relevant version number correctly) and building my distributable with that: Doing so should allow the old version of VFSImporter to work, thus circumventing my reason for creating a custom build.

I mainly hesitate because (A) I’d really prefer to use the newer VFSImporter, and (B) I’ve been working and testing with Python 3.12 and the new VFSImporter, and worry that the change will incur some unforeseen bug… :/

But it might be the best way right now.

Aah, interesting, and thank you for that! :slight_smile:

I did not create a post on this issue, today I found out that the problem does not exist, I called another version of the python interpreter 3.14 instead of 3.11.

So my problem has been solved, but now there is a question about using “manylinux2014”, because two days ago I was able to build a version of my blender exporter for users of Unix systems.

However, the information received in this post requires a correction of the build order.

1 Like