On Nov 15, 2010, at 05:53 PM, Allison Randal wrote: >> Sure, but this is the "consenting adults" argument. The thing is, the >> packages are going to be available in either case, so you're just putting an >> inconvenient sys.path hack in front of anyone who really wants to do it. > >The tricky thing is, we're wrapping lightweight apps in an inconvenient >sys.path hack (to make it difficult to get to application-specific >libraries, for security and isolation) AND trying to make it easy for >new developers at the same time. The tools just aren't up to the job yet.
Right, and as I mentioned in my OP, I think it's entirely appropriate for the apps we're talking about here to use private module paths. I just think that for normal Ubuntu applications, it's largely an unneeded separation. One valid use case though would be if an application does not actually put its supporting code in a library. Then there's no package namespace umbrella that would get installed under dist-packages, so dropping it in a private area and twiddling sys.path makes sense. As an example, look at update manager. It has a package called UpdateManager which contains a bunch of support code. Other than the old skool non-pep8 package name, I see no reason why this would have to be tucked away in a private location. It's not likely that the package name will collide with anything, so seems fairly safe to put in the standard dist-packages location. But since this is embodied in Debian Python policy, this is probably not the forum, and definitely not the thread, to discuss it. Sorry for the noise. -Barry
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
