disappointed by setupTools
Im a little bit disappointed by setupTools. Not that much the tool itself, than the learning curve. Maybe the problem at hand is far from simple, and thats what makes the solution so intricate. http://peak.telecommunity.com/DevCenter/setuptools: this document is 100 pages long! (by page I mean: full screen). easyInstall is 40 pages. I spent about 3 days to figure out what goes where. And I realize Im not done. Yet the documentation is remarkable, great presentation, text is precise and clear, when U read it. Makes U feel guilty U dont find what U lookin for, but U dont find it. I just discovered scripts dont get installed directly (in /usr/local/bin), instead a wrapper in installed, that calls the script. So an extra file is involved, and extra code, every time the script is called. Makes some overhead, and it breaks a simple mechanism I use: my script is able to perform many actions, based on its name (much like cp, mv and ln are the same executable). at install, I need to make symlinks to the script, one per action, and this was automated: this is broken by the wrapping. No big deal, just makes things less simple. Good tools have 2 qualities: - When U need simple things, its easy to use. - When U need more sophisticated things, U dont need to give up the tool for a more powerful one: just have to use extra features. Python is a wonderful illustration of this. While setupTools obviously provides the latter, I consider it fails on the former. I decided to use setupTools after reading, and failing to understand, distutils. setupTools seemed both more powerful and simpler. Probably this choice will save me some trouble later. Im not sure it helped so far.
On Mon, 2006-10-16 at 16:57 -0400, Pierre Imbaud wrote:
I just discovered scripts dont get installed directly (in /usr/local/bin), instead a wrapper in installed, that calls the script. So an extra file is involved, and extra code, every time the script is called. Makes some overhead, and it breaks a simple mechanism I use: my script is able to perform many actions, based on its name (much like cp, mv and ln are the same executable). at install, I need to make symlinks to the script, one per action, and this was automated: this is broken by the wrapping. No big deal, just makes things less simple.
Actually installing scripts with setuptools is very easy: http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation In your entry points simply put the names of the scripts you want and the Python function that script will run. Now you don't need to do your own symlink hack to get it all to work. Just put the functions into a Python module and list them in setup.py. The setuptools method also fixes problems with making scripts work in a cross-platform manner, makes sure your scripts work correctly if someone installs two versions of the same package on their system, and ensures that scripts are run with the correct Python version in case it's not the default Python executable on the system. -- Matt Good <matt@matt-good.net>
On Mon, 2006-10-16 at 16:57 -0400, Pierre Imbaud wrote:
I just discovered scripts dont get installed directly (in /usr/local/bin), instead a wrapper in installed, that calls the script. So an extra file is involved, and extra code, every time the script is called. Makes some overhead, and it breaks a simple mechanism I use: my script is able to perform many actions, based on its name (much like cp, mv and ln are the same executable). at install, I need to make symlinks to the script, one per action, and this was automated: this is broken by the wrapping. No big deal, just makes things less simple.
Actually installing scripts with setuptools is very easy: http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation
In your entry points simply put the names of the scripts you want and the Python function that script will run. Now you don't need to do your own symlink hack to get it all to work. Just put the functions into a Python module and list them in setup.py. works fine, indeed.
Matt Good wrote: problem was I already had this set of functions, but with some general processing before functions get called (for arguments, for instance): Had to dismantle all this to adopt this new policy.
The setuptools method also fixes problems with making scripts work in a cross-platform manner, makes sure your scripts work correctly if someone installs two versions of the same package on their system, and ensures that scripts are run with the correct Python version in case it's not the default Python executable on the system.
granted.
On 10/16/06, Pierre Imbaud <pierre@saiph.com> wrote:
Im a little bit disappointed by setupTools. Not that much the tool itself, than the learning curve. Maybe the problem at hand is far from simple, and thats what makes the solution so intricate. http://peak.telecommunity.com/DevCenter/setuptools: this document is 100 pages long! (by page I mean: full screen). easyInstall is 40 pages. I spent about 3 days to figure out what goes where. And I realize Im not done. Yet the documentation is remarkable, great presentation, text is precise and clear, when U read it. Makes U feel guilty U dont find what U lookin for, but U dont find it.
The current documentation is a reference, not a tutorial. It's long because it's exhaustive. What's needed is different documentation for new users.
I just discovered scripts dont get installed directly (in /usr/local/bin), instead a wrapper in installed, that calls the script. So an extra file is involved, and extra code, every time the script is called. Makes some overhead, and it breaks a simple mechanism I use: my script is able to perform many actions, based on its name (much like cp, mv and ln are the same executable). at install, I need to make symlinks to the script, one per action, and this was automated: this is broken by the wrapping. No big deal, just makes things less simple. Good tools have 2 qualities: - When U need simple things, its easy to use. - When U need more sophisticated things, U dont need to give up the tool for a more powerful one: just have to use extra features. Python is a wonderful illustration of this. While setupTools obviously provides the latter, I consider it fails on the former. I decided to use setupTools after reading, and failing to understand, distutils. setupTools seemed both more powerful and simpler. Probably this choice will save me some trouble later. Im not sure it helped so far.
It doesn't work because you're doing it the wrong way. If you want to see what a command was invoked as, use sys.argv[0]... that's what it's for. Also, you don't *have* to use entry points to make scripts (though it's generally better to)... the scripts kwarg to setup works the same way that it does for distutils. -bob
Bob Ippolito wrote:
On 10/16/06, Pierre Imbaud <pierre@saiph.com> wrote:
Im a little bit disappointed by setupTools. Not that much the tool itself, than the learning curve. Maybe the problem at hand is far from simple, and thats what makes the solution so intricate. http://peak.telecommunity.com/DevCenter/setuptools: this document is 100 pages long! (by page I mean: full screen). easyInstall is 40 pages. I spent about 3 days to figure out what goes where. And I realize Im not done. Yet the documentation is remarkable, great presentation, text is precise and clear, when U read it. Makes U feel guilty U dont find what U lookin for, but U dont find it.
The current documentation is a reference, not a tutorial. It's long because it's exhaustive. What's needed is different documentation for new users. indeed
I just discovered scripts dont get installed directly (in /usr/local/bin), instead a wrapper in installed, that calls the script. So an extra file is involved, and extra code, every time the script is called. Makes some overhead, and it breaks a simple mechanism I use: my script is able to perform many actions, based on its name (much like cp, mv and ln are the same executable). at install, I need to make symlinks to the script, one per action, and this was automated: this is broken by the wrapping. No big deal, just makes things less simple. Good tools have 2 qualities: - When U need simple things, its easy to use. - When U need more sophisticated things, U dont need to give up the tool for a more powerful one: just have to use extra features. Python is a wonderful illustration of this. While setupTools obviously provides the latter, I consider it fails on the former. I decided to use setupTools after reading, and failing to understand, distutils. setupTools seemed both more powerful and simpler. Probably this choice will save me some trouble later. Im not sure it helped so far.
It doesn't work because you're doing it the wrong way. If you want to see what a command was invoked as, use sys.argv[0]... that's what it's for. Thats what I did, thats the obvious way. But with this wrapper policy, sys.argv[0] is the wrapper. to get to the module name, I needed __file__!
Also, you don't *have* to use entry points to make scripts (though it's generally better to)... the scripts kwarg to setup works the same way that it does for distutils.
-bob _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Thanks both of U for your answers. The tool is handy indeed... once U climbed the somewhat steep learning curve.
participants (4)
-
Bob Ippolito -
Matt Good -
Phillip J. Eby -
Pierre Imbaud