Tim Peters and I have recently been beating our heads over what the right approach to deal with scripts in cross-platform software. It's not clear that we've reached any conclusions at all, but I think this is an interesting issue for the Distutils SIG, since distutils is involved in installing scripts. The issue is that the expectations of end-users on Unix and Windows differ substantially. Unix users generally expect that scripts will not have extensions and don't need to have a specific interpreter named on the command line (since that's what sh-bang lines are for). Windows users really expect an icon to click on, and are massively confused by extension-less files. Windows encourages this confusion. Adding a .py extension to Python scripts on Windows allows the user to at least not have to add the path to the Python interpreter on the command line if they want to run the script using the default Python installation (meaning "the one registered to handle the .py extension"). This can be handled by passing a different value to the current script= keyword argument to distutils.core.setup() based on os.name, and having versions of scripts for Windows and Unix. This seems tedious at best, but works, and allows flexibility in implementing the scripts differently for the two platforms. I'm interested in hearing about how others are handling this issue for software that's intended to work on both Unix and Windows. Is there a better approach? I'd love to find a better way to support end-user expectations across platforms, especially if it could involve less magic in the setup.py script. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
On Thu, Jun 10, 2004 at 12:01:29PM -0400, Fred L. Drake, Jr. wrote:
I'm interested in hearing about how others are handling this issue for software that's intended to work on both Unix and Windows. Is there a better approach? I'd love to find a better way to support end-user expectations across platforms, especially if it could involve less magic in the setup.py script.
my $.02... I can't speak to cross-platform issues, but isn't this a behavior that should be handled transparently by the appropriate bdist_* and, maybe, the install, commands? bdist_[unices] can strip the extension and install in the appropriate system directory while bdist_[windowses] could setup an application directory in "Program Files". The setup.py script should be oblivious of such details, and package authors shouldn't have to concern themselves about what platforms their packages might be used on (outside the obvious - packages that use win32 specifics, etc.). mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/
On Thursday 10 June 2004 02:41 pm, Mark W. Alexander wrote:
I can't speak to cross-platform issues, but isn't this a behavior that should be handled transparently by the appropriate bdist_* and, maybe, the install, commands? bdist_[unices] can strip the extension and
I'm not sure, but I could see the build_scripts command dealing with it, at least to some degree. The absence or presence of the extension could be handled at this stage. It may be a minor improvement, but seems like something that should be made easier for the setup.py author.
install in the appropriate system directory while bdist_[windowses] could setup an application directory in "Program Files".
I think application directories are a completely separate issue, actually. I'll try and write something this afternoon to discuss issues related to that. Start menu entries are another area where it would be nice to have better support, but I'm not enough of a Windows user to be aware of what all the issues might be.
The setup.py script should be oblivious of such details, and package authors shouldn't have to concern themselves about what platforms their packages might be used on (outside the obvious - packages that use win32 specifics, etc.).
Ideally, yes. I think distutils could safely deal with the extensions issue without having any impact on setup.py. The possibility of having scripts that are specific to Windows or Unix (or whatever) in a package that is cross-platform is a larger issue and harder to solve. I'd love to have better packaging tools to help me out, though. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
participants (2)
-
Fred L. Drake, Jr. -
Mark W. Alexander