On Jun 14, 2011, at 12:02 AM, Piotr Ożarowski wrote: >it is fine and it is useful... as a submodule, not as a top-level module Agreed! I think I get what you're driving at now. Some applications don't put their Python code or tests in a package. In those cases, yes by all means a private package makes complete sense. >[...] >> >you realize that setuptools/distribute hardcodes versions and forces you >> >to depend on python-setuptools/python-pkg-resources, right? >> >> In the context of Debian, what are the practical problems of this? > >it's 217k of unneeded data that can be easily avoided and few CPU cycles >that can be spared > >anyway, I always say to my sponsorees: if it's not useful outside this >application, make it private and not pollute the global namespace. It >always can be promoted to public one later Agreed. For applications that "do it correctly", I think it's fine for their support package to be public. The principle is: Don't pollute the global namespace! -Barry
Attachment:
signature.asc
Description: PGP signature