Our company (xyz) is moving a lot of our Flash code to Python.
In Flash, we have a shared library between our Flash apps – package xyz. We can make changes to the package without fear of breaking other apps when they are deployed because Flash compiles their code and includes the contents of the library. We deploy the final SWF via RPM, and we’re done. Updates to App1 and App2 won’t ever break App3.
How would you approach this in Python, the shared library dependency.
App1, App2 and App3, could all require xyz-lib.rpm, and all use the same library files, but an updated xyz-lib.rpm would have to be explicitly tested against App1,2,3 every time there was a new library, and this is just onerous.
My current favorite solution – I could make app1.rpm include the library from when it was packaged – effectively some sort of static linking of the library. This, however, feels inelegant. (although the only additional cost is hard drive space == cheap.)
I know that solid management of the shared library is probably the best solution, but I keep trying to factor in that all the developers are human, and will make mistakes. We’re going to make mistakes, and I don’t want a deployment of app1 to break app2 and app3 – it’s just a lot more to test and debug for.
I also favour the solution of packing everything together and limit the dependency on the OS libraries to the minimal (glibc and that’s it). Hard drive is cheap, customer and support time is not.
On windows, it’s trivial with py2exe + InnoSetup.
On Linux, it looks like bbfreeze is the right way to handle this. Quoting from the homepage, it offers: