continuing conversation from UDS-N - Application Review Board

[Barry Warsaw]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101118/7fa59833/attachment.pgp