continuing conversation from UDS-N - Application Review Board
barry at ubuntu.com
Thu Nov 18 20:26:18 GMT 2010
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101118/7fa59833/attachment.pgp
More information about the ubuntu-devel