On May 7, 2009, at 8:54 AM, Paul Moore wrote:
2009/5/7 Doug Hellmann <doug.hellm...@gmail.com>:
I would argue the other way. Why force authors of console scripts
to deal
with entry points instead of just installing the script as-is?
Please explain "as-is" with reference to ensuring that the script
works cross-platform. I think the benefit of entry points for scripts
is that it generates appropriate wrappers to allow use on all
platforms.
I write a python script call hello.py like this:
#!/usr/bin/env python
def main():
print 'hello!'
if __name__ == '__main__':
main()
Why make me define an entry point for that? I can just put it in /usr/
bin or somewhere in the path on Windows and call it as "hello.py".
Does setuptools give me something extra for Windows? I'm not a
regular Windows user, so it's likely that there are features I don't
know about.
Having said that, I find setuptools entry points to be
over-engineered, and the Windows wrappers (in particular, the fact
that they are not version-independent) to be somewhat clumsy. But as a
concept, I like the idea of having a way of specifying that a script
is intended as an "executable", and having distutils do the job of
generating whatever platform cruft is required [1] to make that work.
That's the part I'm not clear about. What "cruft" is needed anywhere?
Of course, for even remotely modern Python versions, I'd argue
strongly that packages shouldn't be including console scripts, but
should rather be supplying modules that can be run as scripts, via the
-m argument to python. Users can then build aliases, shell scripts, or
whatever is appropriate based on that.
Paul.
[1] And note especially that .bat files are *not* suitable wrappers on
Windows, in spite of the fact that they are commonly used. Their
biggest disadvantage is that they don't nest.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
