You are not logged in.
I did some research on distutils, and I managed to find fairly detailed instructions for how one could distribute a Python module with C extensions. However, I have a Python module which uses ctypes to run code from C shared libraries (more specifically: SDL, and related libraries).
Basically, this is what I have:
pslab.py # requires ctypes wrapper modules below
sdl.py # ctypes wrapper modules require respective shared libs below
sdlmixer.py
sdlimage.py
sdlttf.py
# This is for Linux -- .dll for Windows, .dylib for OSX.
libSDL.so
libSDL_mixer.so
libSDL_image.so
libSDL_ttf.so
Is there a "standard" way to distribute modules of this type (maybe some undocumented distutils method, or something I failed to find)?
The Python files are not the problem (distutils can handle them), but I need a way to install the appropriate shared libs for the platform in question (if necessary), so that ctypes wrapper modules can find and load them.
Last edited by Goran (2012-08-14 08:51:19)
Offline
I don't work in python, but generally you'd just list them as a dependency.
I'd be rather unhappy if your package tried to overwrite the shared libraries (extra/sdl) that I already have installed.
edit: pacman would be unhappy too!
Last edited by Trilby (2012-08-12 21:09:02)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Well, as I said: "if necessary".
I'm guessing that there's a fairly intelligent solution that would be able to check for such things. Also, I don't think pacman cares about stuff in /usr/local/lib, right?
If I just wanted to make a package for Arch, this would be a non-issue, but I would like to make my library cross-platform, or get as close as I can.
I could write custom installation scripts, but I'm too lazy, so if there's no standard solution for my install case, I'll probably just list the SDL libs as dependencies, as you suggested.
Thanks.
Offline
You could distribute those files ... but I wouldn't recommend it.
I believe the closest thing to a "standard" is simply to list sdl as a dependency. A package distributor should not try to manage dependencies for users (only inform them of the dependencies). That is either up to the user, or (more often) the distro's package management system.
If I download a program that uses gtk, I don't expect it to include all of the gtk too. Rather, the documentation would simply specify that gtk is a dependency. Are you going to also distribute copies of the python interpreter? Perhaps I'm missing something, but why would sdl be any different than python itself? It's assumed (or speficied) that the user needs to have these installed for your package to work.
Last edited by Trilby (2012-08-13 23:44:44)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
This is not something you should be considering on Linux at all. Ensuring the system has the appropriate dependencies is not your job.
If you're trying to set up a Windows thing, you'll probably have to manually set up an environment for doing just that. I'm not sure how Mac does it.
Offline
Perhaps I'm missing something, but why would sdl be any different than python itself?
Yea, that brings the point home.
I wrote this library as a kind of teaching platform for beginners (I'm working on a Python tutorial series), so I thought that making things as easy as possible would be pretty important. However, it now occurs to me that satisfying dependencies is something that they'll have to learn sooner or later, so it might as well be sooner.
Thanks for all the help guys.
PS: If anyone is interested in the library, it's up on github: pslab
Offline