As an aside, I notice that Debian Python Policy begins by assuming people know
what "private Python modules" are, but this will not be the case for most
Python developers unfamiliar with Debian conventions. Section 2.1 briefly
mentions the distinction from a sys.path-visibility point of view, which
doesn't really explain much. I'd like to see a section early on which defines
private modules, where, when, why and how they should be used, etc.
On Jun 10, 2011, at 10:13 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2011-06-10]
>> Ah, yeah. Y'know, I am personally not a fan of private modules anyway :).
>
>/me waits till Barry will try to package his 13th package with
>Python application that uses "lib" or "tests" module names...
>(or will he break after 4th? Bets anyone? ;)
I know this has been discussed before, and there's even debate about it
upstream, so apologies for rehashing it. My own personal opinion is that it's
fine to include things like a `test` (Python) subpackage in the (Debian)
package python-foo. It aligns with the Python "consenting adults" motto, and
I think such things *can* be useful. As long as the top-level package name is
unique, subpackage can't pollute the global namespace, so I don't care.
>> Note too in a setuptools(?)/distribute/packaging world, you might not
>> actually have a `foo` script in the source at all. For example, Mailman 3
>> has this in its setup.py:
>>
>> template = Template('$script = mailman.bin.$script:main')
>> scripts = set(
>> template.substitute(script=script)
>> for script in ('mailman', 'runner', 'master', 'onebounce')
>> )
>> setup(
>> ...
>> entry_points = {
>> 'console_scripts' : list(scripts),
>> },
>> ...)
>>
>> so in fact /usr/bin/mailman doesn't exist until the system is built out.
>> /usr/bin/mailman gets generated and essentially imports the
>> `mailman.bin.mailman` module, then runs the main() function.
>
>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?
-Barry
Attachment:
signature.asc
Description: PGP signature