On Sat, Dec 22, 2012 at 11:00:35PM +0100, Bas Wijnen wrote: > Hello, > > I have a Python program (of which I am upstream) and I want to package > it. However, it has some private modules and I don't know how to treat them. > > Section 3.1.1 of the Python Packaging Policy says they should be in > /usr/share/. This makes sense, being private data of the package.[1] > > However, this doesn't seem to be how Python programs normally work. I > asked on IRC (freenode:#python), and the response was that Python > programs don't have the concept of "private modules". Any module, no > matter how program-specific, is installed publicly. This feels wrong for > me, and not "the Debian Way".
Remember, binaries can see local modules - if you drop the program into /usr/share as well, and link it into /usr/bin, it won't be system wide, and it will be importable -- so, there is this concept (sorta). > > This wouldn't be a problem in itself, but I need support from the Python > system to make things work: my program needs to import my private > module, which means its directory must be in sys.path. But how do I get > it there? I see several options, none of which seems really good: > > 1. Hard-code the directory in the program. > + It works. > - It will then only work on Debian > - It cannot run from a different path. > > 2. Let the upstream program assume that the module is in the search path > (either installed publicly or in the same directory as the script). Use > a debian patch to add Debian's private path to it. > + It works. > + The upstream script works for non-Debian people. > - The patch may not apply cleanly in a next version, so it slightly > increases maintainance burden. > - The packaged program is not the upstream version (is that actually a > problem?) > > 3. Create a module for handling this. I import the module and call a > function on it providing my package name. It will add the required > directories to sys.path. > + This would be great, if it worked, but: > - Othes operating systems don't have this module, so even though the > approach is intended to make it more portable, it actually makes it > Debian-specific. > > 4. Virtualenv was suggested on IRC. I'm not sure how I should use it; it > seems like a tool for users with little permissions on the system, not > for a package which can access anything. But I might be wrong, so I > wanted to mention it. Yeah, please don't use virtualenv, as much as I'd like to see a good way of using virtualenv in Debian. > + ? > - ? > > 5. Create a wrapper executable script which just runs the program from > /usr/share. Have the private module in the same directory as the > program. (I've seen this used by freealchemist.) > + It works. > - It's a clumsy workaround. > > 6. Make /usr/bin/program a symlink to the actual file in the private > directory. It will then search in its real place. (I've seen this used > by angrydd.) > + It works. > + It's not as clumsy. > - It still seems to be a workaround. > - It is not obvious to a user who copies the file and changes it, why > the copy doesn't find its modules. > > Any thoughts on this are welcome. > > Thanks, > Bas > > Ps: please Cc me on replies, I'm not subscribed to this list. > (And keep these lines, so I alse get replies to replies.) > > [1] Actually, it says it should go in /usr/share/modulename/, while I > would expect it to go in /usr/share/packagename/.../modulename/. Am I > misreading this? In particular, should package foo (with private module > bar) really create /usr/share/bar? > -- .''`. Paul Tagliamonte <paul...@debian.org> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag
signature.asc
Description: Digital signature
