> 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".
With an entry point, hello.py could simply be: def main(): print 'hello!' But I agree, the Distutils 'scripts' is conceptually simpler. Especially since it let's you run a script 'as-is' without first running an install tool to generate a script wrapper. It's only once a script has dependencies on other Python libraries where relying on those libraries being available for import may not work. In this case, the 'scripts' field forces the user to install those libraries in a global location (site-packages), this isn't always desirable though! As for including BASH scripts in the 'scripts' field ... I dunno. Clearly entry_points are meant to only annotate Python code! Is including BASH scripts in the 'scripts' field an abuse of Distutils or is it acceptable usage? The Distutils docs aren't explicit on this, so I'm inclined to say it's acceptable, so this is at least one good reason for keeping the 'scripts' field. But then having both 'scripts' and 'entry_points/console_scripts' is less than perfect since it introduces (mostly) unneccessary TIMTOWTDI. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig