3 ms·
Suppose you're trying to distribute a piece of binary software that comes with different features, such as a build that includes only client applications, while
by philipov 4y ago
Suppose you're trying to distribute a piece of binary software that comes with different features, such as a build that includes only client applications, while another one also includes both client and server applications. If they both depend on the same shared library that needs to be included with the distribution, and come with the same python API, making it so you can't separate features into isolated packages, what's the best practice for packaging each bundle as wheels?
Would you name one package `software_server`, another `software_client`, but call the shared python component `software` in both of them?
Also, how do you manage versioning when the version of the binary software is independent from the version of the python wrapper around it?
- maxnoe 4y agoThis is not possible using wheels. Binary wheels cannot depend on shared libraries outside the wheel besides a small number of System libraries. If you want to distribute a python package like this, you could use the conda forge eco system and have a package for the base library and then other packages depending on that, e.g. foo-core foo-server foo-client
- philipov 4y agoYou can't depend on shared libraries outside the wheel, but you can include the library inside the wheel. The applications all expect the shared library they depend on to be in a path relative the location of the application, which prevents putting the shared library in a separate package anyway. So how would you handle this situation with wheels if you don't have the option of forcing users into a specific python distribution?
- maxnoe 4y agoMaybe I misunderstood. After rereading, I think so... I thought you wanted to distributed a shared library im one package and then have other packages depend on that. So it's not clear to me what your actual Situation is