Hi Mark, Shortcuts don't, but file associations to those shortcuts do (at least to the best of my understanding,) adding paths does, etc. I agree that a library (extensions or no) doesn't need to do these things. But anything targeted at an end-user on Windows has a reasonable chance of wanting them. Here I thought I was being pretty clear that I was only requesting that things not be done to explicitly make it hard (or impossible) for someone else to extend setuptools (or whatever replaces / refactors it) to do these things. -- Dave Mark Hammond wrote:
Even installing shortcuts doesn't need to munge the registry! But regardless, you seem to be arguing that setuptools should morph into a full-blown, general purpose installer for python build apps, capable of doing all kinds of platform specific things which any app may desire -- and while I don't agree with that, it wasn't what was being discussed at all. Writing and installing a Python extension does not need to munge the registry. Installing a general purpose application, written in Python or anything else, will require, in the general case, anything you could possible imagine.
Mark
*From:* Dave Peterson [mailto:dpeterson@enthought.com] *Sent:* Wednesday, 2 April 2008 3:30 PM *Cc:* Mark Hammond; distutils-sig *Subject:* Re: [Distutils] [Python-Dev] How we can get rid of eggs for 2.6 and beyond
Mark Hammond wrote:
(Note: I'm aware that people believe it to be necessary to munge the
Windows registry when installing Python packages; I just don't agree
with the practice, and don't think we should distort Python's process
to coddle it).
Whoever thinks it necessary is misguided. Installing a package doesn't require munging the registry and none of the popular installation techniques do. Installing Python itself does, and some packages have special requirements (eg, pywin32 registering COM objects), but in general, Python packages on Windows can ignore the registry.
I guess I'll step up and volunteer myself as 'misguided' then. :-)
I would very much like to be able to package up my application or library such that it created desktop/start menu/quicklaunch icons for various things like running the app, running examples, opening docs for browsing, etc. I'd also like to be able to associate certain file types with executables/scripts/shortcuts provided by the installation of my project. After all, Windows users in general are not as technically adapt when it comes to command line tools so setting up these nice GUI ways of doing things adds usability significantly.
You could argue (like Phillip has) that these operations should be done via an explicitly user-invoked script, and I can buy that for the standard version of the tool. You could also argue that installing applications (which is generally where these kinds of desires come into play) is not the job of the tools we're discussing. But it seems to me that the existing capabilities of setuptools are 80% (or more) of the effort in creating a tool that would allow installation and efficient maintenance of large Python-based applications, such as what my employer delivers to customers.
All that being said, I'm fine with the idea that the standard library version of the tool does not enable this. Just so long as nothing is done to actively prevent extensions of that tool to do this sort of thing for those who need or want it.
-- Dave