Deploy-ng: No "bdist_apps", no "panda3d" in pip list?

General Discussion
1

I’m attempting to build a distributable demo via deploy-ng, and I’ve hit a problem:

According to the documentation, having created a “setup.py” file, I should run “python setup.py bdist_apps”. Unfortunately, when I do that it produces the following error:

error: invalid command 'bdist_apps'

Doing a bit of research, I found this thread. In that thread, Moguri asks after the value for “panda3d” in the output of “python.exe -m pip list”. In my case… there is no entry for “panda3d”.

Now, I’m using a home-built version of the “deploy-ng” branch of Panda3D 1.10. Specifically, I built it using the “–installer” parameter. Thinking that perhaps this was the problem, I tried to build it with “–wheel” instead–but that brings me back to the problem that I previously described in this post. (In short, while “libpython2.7.so” does exist on my system, it’s not located where “ldd” seems to expect it to be. I could make a link to it, but I’m concerned that this might just patch over an unknown and possibly-more-serious problem.)

So, what might I do in order to get deploy-ng working on my system?

(I’m doing this under Ubuntu 16.04 (“Xenial”).)

2

Normally, when you install panda3d via “pip install panda3d” or by building a .whl and using “pip install panda3d*.whl”, it should automatically register the bdist_apps endpoint with setuptools.

When you build Panda from source, and then run it by setting PYTHONPATH to the built directory instead of by building and installing a wheel, it should also be taken care of automatically because of the presence of the built/panda3d.dist-info directory, the presence of which tells setuptools about the existence of deploy-ng.

How are you using Panda3D if not via either of these two methods? Did you use --installer and then install the resulting .deb? If so, it may be that you manually have to copy panda3d.dist-info into your python installation’s site-packages/dist-packages directory, and that we have simply overlooked this means of installing Panda.

3

Ah, I see…

Exactly.

Hmm… Looking into finding the location of “site-packages”, I discovered the “python -m site” command. Running that, I see the my “panda3d/built” directory is in the “sys.path” list–which should mean that it’s a global site-package, and thus should, I would think, have access to that “panda3d.dist-info” directory… o_0

However, creating a local site-packages directory (“~/.local/lib/python2.7/site-packages”) and copying the “panda3d.dist-info” directory into that seems to have allowed bdist_apps to run! :smiley:

Hmm… It seems that I’m supposed to have a “requirements.txt” file, which would point to a wheel for Panda3D. The examples that I’ve found on the forum seem to have it pointing to a wheel on the Panda3D archive server. Since I’m using a home-built version, I presume that this isn’t what I want–that I should point it to a wheel of my own? If so, that brings me back to the question of how to build a wheel on my own machine…

4

You can put something like this in your requirements.txt file:

-f /path/to/directory/containing/your/whl/file/
panda3d

Then it will use the .whl files that are inside that directory, given that they match the Python version and platform tags.

5

Ah, thank you–that makes sense, I believe. :slight_smile:

The question, then, is how I actually make a wheel-file. As noted above, when building with the “–wheel” parameter instead of “–installer”, “ldd” is trying and failing to find “libpython2.7.so”. Should I patch over the problem by making a link in the location that “ldd” is looking in–or is there some underlying issue that should be fixed?

6

All right, I’ve taken the risk and simply created a link in “usr/lib” to the “libpython” file found in the “x86_64-linux-gnu” sub-directory, I believe, and it seems to have worked: I’ve successfully built a “wheel” version of Panda3D and installed it via Pip.

In turn, the command “python setup.py bdist_apps” now works, too–but I’ve hit a new snag there:

While the command works, it seems intent on downloading a copy of Panda3D from the Panda server.

With the requirements.txt given above, it seems to attempt to download Panda3D 1.9.4.

Having hunted around the forum a little, I tried adding “==1.10.0” after “panda3d”, in which case it produces the following error:

Could not find a version that satisfies the requirement panda3d==1.10.0 (from -r ./requirements.txt (line 2)) (from versions: 1.9.3, 1.9.4, 1.10.0.dev1182)
No matching distribution found for panda3d==1.10.0 (from -r ./requirements.txt (line 2))

Judging by the presence of 1.9.3 and 1.9.4 in that list, as well as the “.dev1182” suffix after 1.10.0, I’m guessing that it’s still looking at the server for some reason. :confused:

If I specify “panda3d==1.10.0.dev1182”, it attempts to download that version, I believe.

My “requirements.txt” file, as it currently stands:

-f "/home/thaumaturge/panda3DWheel/"
panda3d==1.10.0

(“panda3DWheel” is a directory that I created to make for a cleaner file-path than my Panda3D working directory had, thinking that perhaps that was the problem, as I recall. Since it is a cleaner and simpler path, I’ll probably stick to it, even though it doesn’t seem to have helped.)

Within “panda3DWheel”, I have the wheel-file generated by building Panda3D, named “panda3d-1.10.0-cp27-cp27mu-linux_x86_64.whl”.

Any suggestions? :confused:

7

Which location did it try to read libpython from, and which location was it actually in?

I don’t think you should add quotes around the -f option, but I don’t know if it matters.

You shouldn’t need “==1.10.0”, since it should automatically prefer the higher-numbered version.

I suspect that you have “manylinux1_x86_64” in your platform list even though the platform tag of the .whl you built is “linux_x86_64”. So, use that instead in your platforms list to use your local .whl.

8

I believe that it’s trying to read it from “usr/lib”, when it was in fact located in “usr/lib/x86_64-linux-gnu”.

Fair enough, and done! I originally added the inverted commas because the original directory included spaces, and simply left them in place when I moved the wheel file to a new, simpler path.

Fair enough, and noted! It was done in response to the system seemingly attempting to download 1.9.4 by default, I believe.

Ah, you’re quite right! I took the “manylinux1” version from the setuptools documentation; it didn’t occur to me that there might be another designation, or that there was anything wrong with this one.

And changing it as you’ve suggested seems to allow the process to complete! I now have a linux zip file containing the game! :smiley:

However, there are still some problems (the resultant program crashes on startup, for one)–but I’ll start a new thread for the process of creating a working build, I think, as it’s straying somewhat from the subject of this one…

9

manylinux1 is a specific distribution of Linux that contains libraries that are compatible with (almost) all Linux distributions out there. The official Panda builds are made on this distribution to remain compatible with almost every Linux machine.

Since you are not building on that Linux distribution, your own builds don’t get this tag, and they are simply given the generic “linux” tag. This means they aren’t guaranteed to work on any Linux distribution other than your own.

10

Ah, I see… Hm… I’m building under Ubuntu 16.04, I believe, and I’m a little surprised that it doesn’t (or isn’t noted to) have that compatibility. What distributions do get the “manylinux” tag?

Still, Windows builds are probably more important anyway.

11

Manylinux1 is a docker image being provided by the Python packaging community, and it is based on CentOS 5.

It needs to be a very old Linux distribution, since a library built against libc 2.26 (as is included with Ubuntu 16.04) will not work with any distributions that ship an older version of libc. CentOS 5 ships with a very old version of libc, 2.5, so it is more likely to work with other older versions of Linux. The same logic applies to other core libraries as well. More information about this is in PEP 513.

However, you could use docker to virtualise the manylinux1 images and build Panda in there. You can also use the panda3d-thirdparty scripts to build the thirdparty packages that you wish to include.

12

Ah, I see–thank you for the explanation.

Hmm… If, as suggested in the other thread, the official 1.10 wheels don’t have any licensing issues, then it might be simpler for me to switch to using those. That would obviate the question of building a “manylinux” version of my own, and in general simplify matters for me, after all.

(If not, and if I end up deciding to release distributable Linux builds, then the information given may prove rather useful–thank you again!)

13

I’m trying to building the latest master on Ubuntu 16.04 and come across the mentioned Python path problem. Is there way to overcome it other than copying/linking the .so file to /usr/lib?

14

How did you install Panda3D? If you point your PYTHONPATH to the built directory, I think that should be sufficient. You can also pass either the --installer or --wheel flag to makepanda and install the resulting .deb or .whl, which should also work.

15

No, I didn’t point PYTHONPATH the the built directory. I simply ran makepanda/makepada.py providing --use-python and --wheel among other options. And I’ve run into exactly the same problem that the OP had got. I was able to circumvent it by hard-coding the path to the shared library:

diff --git a/makepanda/makewheel.py b/makepanda/makewheel.py
index 2c0d053..06c0b56 100644
--- a/makepanda/makewheel.py
+++ b/makepanda/makewheel.py
@@ -731,6 +731,8 @@ if __debug__:
     else:
         pylib_name = get_config_var('LDLIBRARY')
         pylib_path = os.path.join(get_config_var('LIBDIR'), pylib_name)
+        pylib_path = '/usr/lib/python2.7/config-x86_64-linux-gnu/libpython2.7.so'
+        print('XXX', pylib_path)
     whl.write_file('deploy_libs/' + pylib_name, pylib_path)
 
     whl.close()