[Distutils] Adding entry points into Distutils ?

[Doug Hellmann]

On May 7, 2009, at 8:54 AM, Paul Moore wrote:

> 2009/5/7 Doug Hellmann <doug.hellmann at 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.