King wrote:
On Jul 8, 2:21 pm, Alexander Kapps <alex.ka...@web.de> wrote:
King wrote:
Hi,
I am writing a python package deployment tool for linux based
platforms. I have tried various existing
tool sets but none of them is up to the mark and they have their own
issues. Initially I'll start with simple approach.
I'm sorry, but your approach is not going to work. The Right Way(tm)
is to not ship any external libraries, but let the user install the
dependencies with the distro's package manager. And to not try to
build custom packages, but to let the package maintainers of the
different distros package your application for you.
Yes, you an do this by creating a .deb package that will take care of
installing the required libraries.
It may possible that either required version is not available in the
distro's repository or the one available is
older one then required.
Yes, that may happen.
So best deal would be to ship at least all
the python's libs along with your package.
No, IMHO, the best way to cope with this, is to be a little
conservative on what library versions you use. Don't use the most
cutting edge versions, but those who are most wildly available.
Even if you must use the most recent versions, you should leave the
packaging to the distro maintainers. They know their distro a lot
better and know how to maintain compatiblity with the rest of the
system.
1. Find all the modules/packages and copy to "lib" directory.
2. Find python's *.so dependencies(system libs) and copy them to
"syslib"
That would include all the way down to libc, your archive is going
to be huge, but the actual problem is, what if the libc isn't
compatible with the kernel, what if the WX, GTK, X11, etc libraries
aren't compatible with the running Xserver?
You are right here. It seems there is no standard definition of system
libraries on linux. To over come the problem of binary
compatibility, I am using ubuntu (hardy) which is on glibc 2.7. Every
other external python library including python is compiled on
hardy. This is would give you maximum chances that libs would be
compatible in case if you run on any other distro which is using glibc
=2.7
Just because any other disto is based on glibc 2.7 doesn't ensure,
that the other parts (like gtk libs vs. X11) are compatible.
Actually by doing so, you are limiting your package to Hardy only.
Any compatiblity with other Ubuntu versions or other distros would
be purely by accident.
End of the story is, you would need to package a minimal (but almost
complete) Linux system into your package, which of course is not
want you want.
3. Copy python(executable) and libpython2.6.so.1.0 into "dist"
directory.
4. Set up temp environment
5. Run main script using "python <main script>.py"
The idea is to produce a cleaner directory structure. Neither I am
creating a boot loader nor I am converting main script
file into executable. It's plain vanilla stuff.
It's not vanilla stuff, but a very hard problem. In fact you are
fighting against the whole system structure.
Ok, forget about system libs(libX*.* etc.), I don't know why it sounds
too complicated. I am hoping it should work and eventually it's easier
then tools that create an executable using bootloader. The problem is
in setting the correct python environment.
It sounds complicated, because it is complicated. :-)
Now, imagine, everybody would do this. There would be dozens, maybe
hundreds of redundant copies of Python, libXYZ, etc.
I don't know what you mean by "create an executable using
bootloader", but really, the correct way is to leave the dependency
management to the distro and it's package manager.
--
http://mail.python.org/mailman/listinfo/python-list
