Is there a way to include third-party packages in .whl file when compiling Panda3d?

Compiling or Editing the Panda Source
1

Hi, community,
I am trying to install panda3d on cluster and make it work under GLES2 graphics pipe, and it almost succeeds. But now I encounter a sticky problem. Since the panda3d installed by pip from official source doesn’t support GLES2 pipe, then clurster users of my program have to build panda3d from source code to enable it. However, it is hard for most users to get Admin permission on cluster to install third-party packages via Sudo, such as libbullet-dev, libpng, and so on. So I try to provide a .whl file which is built on my own sever for the cluster users, but the third-party packages are still needed to run panda3d application. And I’d like to know can I include the third-party packages in the .whl file when compiling panda on my own sever so that the cluster users can install panda3d only by the .whl file quickly without compiling from source code and asking for Admin permission.

Actually, @rdb has told me that the pandagl can also work on cluster in EGL environment, which means cluster users can also install panda from the official source and don’t use GLES. But in EGL environment running my program will report bug.

Thanks,

2

What prevents you from creating a package with the necessary dependencies?

1 Like
3

Yes, you can. When you build the thirdparty packages as static libraries, such as is done when you build them using this script, they will effectively be included in the built wheel. This is what we do with the official wheels.

You might want to build Panda inside the “manylinux” docker container if you want to distribute it to other Linux systems, to make sure they work on a reasonable set of Linux systems.

You can also use the deployment system to create a self-contained build of your application, as @serega-kkz pointed out.

1 Like
4

@serega-kkz @rdb, thanks for your quick reply. And what you did in official wheels is what I want. Thanks!!

5

… Is there a complete set of scripts/steps for a self-contained distribution?

The static-linked libraries don’t appear to be used in any of the CI scripts for Ubuntu (uses apt dependencies). There are some scripts that just use cmake, and some that are using makepanda, but since there doesn’t appear to be a publish/deploy step it’s hard to trace what’s used to build the wheel for deployment. Am I just missing something, or is the build not fully traceable?

6

The GitHub Actions CI is a relatively new addition to our tools, and it is not yet used to build the official distribution. Those are being built via our Buildbot instance, and the scripts for those are here:

The way we build the Linux wheels is a little complicated, since we have to build it with an old Linux distribution so that we’re sure that the resulting wheels will work in any desired Linux distribution, so we do it via Docker. The actual meat of the build process is a one-liner, with the --wheel flag being used to produce a whl:

The Dockerfiles that produce the Docker environment to build these in are in the dockerfiles folder in the same repository. It’s these Dockerfiles that build the dependencies statically, from the rdb/panda3d-thirdparty repository:


However, your own builds may not need this level of complexity. If you are intending to run in a known environment (such as a Docker image you are producing yourself), it may be sufficient to build on the matching platform, and just produce the --wheel directly.
7

Ah, thanks, that’s what I was looking for.

I am building this in a known container, so no, I don’t need most of this (and can install all the dependencies that aren’t getting included anyways). I was just confused about why my custom builds were complaining about them when the official one wasn’t.