>> Glen wrote: >>> So let's further say that the .zip file was named .py, instead, but was >>> a .zip internally. >>> > > So this cures the icon too, maybe you realized that.
It takes it to 80% cured. Being the purist that I am I still long for the day when I can see a python package in my file manager with a proper icon. Icons only cost $400 to get done professionally at a graphic artist. That's roughly the same as a round of drinks at a python conference. I'd like to see a pythonic egg icon. I know from experience graphic artists can knock together a nice set pretty easily. > A ZIP named .py doesn't need to be "installed" it can just run in > place. And as a couple other subthreads noted, this is already > functional in Python 2.6/3.1 today. It's not that I forget or didn't understand, it's that the inplace concept doesn't sit nicely in a formal windows environment. You have to accept my word that there is a 'tradition', started by Microsofts 'guidelines' over 20 years ago about where windows users must put their programs. I can tell you about places where I have contracted where the desktops are "cleaned" of any "inplace" files. If I spent a week doing an application, I would want it to last on a system well into the next day.. To get around that, we simply put the programs where microsoft tell us and the data similarly and everything is sweet. > Of course, if you want to create a ZIP named .py package that is an > application installer, you could do that, too. It might be handy for > the case where not everything in the application can be a .py, .pyc, or > .pyo... shared libraries cannot be run from the ZIP files as a > documented limitation, it seems... so if those are needed, then an > installer is needed too. Yes.... now I *really* *like* that idea... > But it does seem that a ZIP name .py installer > package could carry other payloads in the ZIP file, and those payloads > could be extracted a places in the right places. Yes. If the user wishes, why not. Good idea >>>> Double click them ... > Here the Windows technique > of associations, also mentioned in another subthread, do make it easier > to actually _click_ on the thing and have the right thing happen, > whereas Unix/Linux must have the #! line, If you are without an X11 window manager such as gnome or kde and are command line bound that is true. If you have Gnome/KDE then they both give you the association capability under Linux/Unix. > Without reference to distutils, it seems the pieces are: > > 1) a way to decide what to include in the package > 2) code that knows where to put what is included, on one or more platforms > 3) the process to create the ZIP file that includes 1 & 2, and call it > an appropriate name.py Yes. > 3 looks easy, once 1 & 2 are figured out. distutils might provide the > foundation for 1. 2 sounds like something a distutils application might > create. I'm not sure that distutils is in the business of building > installer programs, my understanding is that it is in the business of > providing a standard way of recording and interpreting bills of > materials and maybe dependencies, but that is based only on reading > discussions here, not reading documentation. I haven't had a chance to > read all the module documentation since coming to python. Well, the package building technology within python is quite old at the moment. According to the Pycon-convention program Tarek is talking about doing a revamp of distutils. I can't tell you what the exact plan is so you'll have to follow that one yourself. In the last one year, I've done some work on coming up with a more modern system but only have had time to do sporadic work. Here's where I hack about..: http://bitbucket.org/djlyon/ Right now I'm kindof busy working on a package test robot for pypi along the lines of cpants. But I'd love to see some of this come together so you would be more than welcome to join in and help on my community project shown above. I have to keep my postings to a minimum here, because (rightly) I've been told to code and not blab, blab, blab all the time. But I'm happy because every now and again something I say gets picked up and put into action. Best Regards David _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
