[Distutils] [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Dave Peterson]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20080402/1c978521/attachment.htm