On 7/25/18 10:58 AM, Greg Couch wrote:
Short answer: wheels are regular python builds.
ChimeraX is designed so that the bundles can be upgraded separately. The bundles are packaged using the normal Python packaging mechanism, wheels. The wheel package is installed as part of the build process. In your case, there will be no FreeBSD bundles in the ChimeraX Toolshed, so that is not an advantage for you, but it is a huge advantage for our Windows, macOS, and Linux users.
You probably explained this before, but out of curiosity, since FreeBSD can run Linux binaries, why aren't you starting with the Linux tarball for FreeBSD? The biggest problem is probably PyQt5. You could replace the distributed PyQt5-commercial package, with one built on FreeBSD. Other missing shared libraries could be placed in CHIMERA/lib. And you'd be done! :-) Obviously, you can't legally redistribute your version since you don't have a commercial PyQt license, but you could redistribute your script to other FreeBSD users.
Running linux binaries with UI and a lot of dependencies can have its own problems with availability of dependency ports for linux dependencies, etc. I chose to build a native package.
Does ChimeraX use some functionality from the PyQt5-commercial package that isn't available in the free PyQt5 distribution? (Supposedly, the commercial package has extra functionality? I'm not familiar with this commercial package.) What does "Other missing shared libraries could be placed in CHIMERA/lib." mean?
No ports use wheels, even though wheels is a python standard. PyPI website normally has a source tarball that builds into a python package (a directory with .py/.pyo/.so files), and then they can be packages into a wheel when desired. Virtually all python packages do this.
Now I have to figure out how to separate wheels from the build.
Distribution-wise, it will be distributed as a freebsd package through the normal channels, to whoever installed FreeBSD or its derivatives and wants to use this package.
Yuri