Hello I really like the way setuptools wraps scripts depending on the platform. http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation I am not talking about the entry_point feature, but the way it creates executables. What would people think about making that feature go into distutils itself to enhance the current script behavior? http://bugs.python.org/issue870479 Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
On 2009-02-14 06:26, Tarek Ziadé wrote:
Hello
I really like the way setuptools wraps scripts depending on the platform.
http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation
I am not talking about the entry_point feature, but the way it creates executables.
What would people think about making that feature go into distutils itself to enhance the current script behavior?
I have a couple of issues with this feature as implemented in setuptools. I think they should be addressed if the feature makes its way into the stdlib: 1. The pkg_resources import can make startup time quite large. For small command-line utilities like my grin tool and DivMod's PyFlakes, this can make them unusable. If you bring the feature into the stdlib, please pay attention to the overhead of locating the real script however you end up doing it. 2. In the generated script, please use "if __name__ == '__main__':" to block out the executable bits. Currently, multiprocessing does not work on Windows when the application is started by a console_script. Because Windows does not have a true fork, multiprocessing will start up clean Python subprocesses that import the __main__ of the parent process. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Sat, Feb 14, 2009 at 11:23 PM, Robert Kern <robert.kern@gmail.com> wrote:
I have a couple of issues with this feature as implemented in setuptools. I think they should be addressed if the feature makes its way into the stdlib:
1. The pkg_resources import can make startup time quite large. For small command-line utilities like my grin tool and DivMod's PyFlakes, this can make them unusable. If you bring the feature into the stdlib, please pay attention to the overhead of locating the real script however you end up doing it.
Right, it getting very slow when you have a lot of sitedirs and .pth files, I think an API in pkgutil should handle this part and focus on performances, There's a patch I have started for this, that takes back pkg_resources import principles to look for a packages to return their metadata. http://bugs.python.org/issue4908
2. In the generated script, please use "if __name__ == '__main__':" to block out the executable bits. Currently, multiprocessing does not work on Windows when the application is started by a console_script. Because Windows does not have a true fork, multiprocessing will start up clean Python subprocesses that import the __main__ of the parent process.
OK, I'll point this thread in the ticket Tarek
2009/2/14 Tarek Ziadé <ziade.tarek@gmail.com>:
I really like the way setuptools wraps scripts depending on the platform.
http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation
I am not talking about the entry_point feature, but the way it creates executables.
What would people think about making that feature go into distutils itself to enhance the current script behavior?
I mentioned this on the ticket, but I'm adding it here for comments: If this is to go into the stdlib, can it be implemented in such a way that creating a bdist_wininst installer for a pure-python package with wrapped scripts does *not* make the package version-dependent? Paul.
participants (3)
-
Paul Moore -
Robert Kern -
Tarek Ziadé