Re: [Pythonmac-SIG] py2app standalone options
On 21-dec-2004, at 23:42, has wrote: Chris Barker wrote: I originally came down on Has' side of this debate, but now think Bob has made the right choices, so I thought I'd add a couple comments. First, I'm a little unclear on what exactly Has wants. Could you clarify? Freedom, basically. It's easier to assemble a workflow by mixing and matching small, single-purpose components than to strip down a great big monolithic lump to get the pieces you want/need. If you're going to protect the end user from doing stupid things, that's great, but it should be done by the next layer up. Users who work at the top layer are protected; users who want/need to route around the 'dummy mode' restrictions can go in at the layer beneath. After all, it's the user's foot, and if they want to shoot holes in it in full knowledge of what they're doing then far be it for anyone or anything else to stand in their way. rant You obviously don't want it badly enough. Adding an option that will make the application not include stuff from site-packages is not much work, the patch is less that 100 lines (context-diff) and it took me less than half an hour to write it. /rant The basic architecture of the code looks just fine, and py2app does what it suppposed to do. The packaging needs some work (where's the documentation?), but this is a 0.x release after all. For example, appscript currently takes this approach. The lower-level aem package provides a comprehensive wrapper around the AEM; appscript builds on this to provide a nice, safe, friendly-looking user interface for application scripting. Most folks'll just use appscript for all their application scripting, but geeks who need access to the full AEM, e.g. to send asynchronous events, can use aem. Prior to 0.6.0 appscript was a monolithic system, which meant you were SOOL if you wanted to do async events, for example - an issue Bob also happened to raise at the time. To give a practical example, let's say I want to write a GUI interface to py2app. My main dialog has some text fields and checkboxes for basic setup info, plus a table view listing all dependencies, allowing users to check/uncheck the items they want/don't want included. The obvious way to implement this would be to call modulegraph to generate the table content, then take the list of checked items and feed it to py2app's package-building function via an 'includeitems' argument. I really don't want or need py2app to run modulegraph a second time just because it's been welded into the basemost layer. That's an application with different requirements than py2app, and that should be easy enough to build using the building blocks of py2app. BTW. the GUI I'd like to see is a GUI that allows me to grafically construct setup.py files. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 22, 2004, at 6:49, Ronald Oussoren wrote: On 21-dec-2004, at 23:42, has wrote: Chris Barker wrote: I originally came down on Has' side of this debate, but now think Bob has made the right choices, so I thought I'd add a couple comments. First, I'm a little unclear on what exactly Has wants. Could you clarify? Freedom, basically. It's easier to assemble a workflow by mixing and matching small, single-purpose components than to strip down a great big monolithic lump to get the pieces you want/need. If you're going to protect the end user from doing stupid things, that's great, but it should be done by the next layer up. Users who work at the top layer are protected; users who want/need to route around the 'dummy mode' restrictions can go in at the layer beneath. After all, it's the user's foot, and if they want to shoot holes in it in full knowledge of what they're doing then far be it for anyone or anything else to stand in their way. rant You obviously don't want it badly enough. Adding an option that will make the application not include stuff from site-packages is not much work, the patch is less that 100 lines (context-diff) and it took me less than half an hour to write it. /rant You did write it incorrectly, though. You didn't make it imply --site-packages (non-working executables by default!), and you didn't check to see if it was compatible with Python 2.4. site.sitedirs, or anything equivalent, does not exist in Python = 2.4. The former is easy to fix, but the latter is not. Additionally, the filter stack is stronger than includes so you certainly wouldn't be able to actually use it to do the use case that Has' fabricated. Needless to say, this functionality won't be popping up in 0.1.7 :) -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Question about Pil and icns...
On Dec 22, 2004, at 7:09 PM, whamoo wrote: I've read that new beta of the Pil now add support for icns file format, nice, but in the code of the plugin i read that there is only the read support, so, i cannot convert icns in other format and vice-versa? And if i load icns, work on it, then i cannot save. Can someone tell me something about it? Someone have tried? That is correct, this is read-only support. You may not save icns files with the code in PIL. You could of course do it the native way, using Mac APIs, or just by dragging images into Icon Composer. My use case was that I had application resources in the canonical Mac OS X formats, and I wanted to re-use them in a Windows port of the software... so I wrote an icns decoder for these files (I used the 128x128 version of the icon in the UI), and all the string localization support from Foundation. I did of course need regular windows .ico files for the applications, but typically they only go up to 48x48, so I still wanted to re-use my .icns file rather than maintain a separate png of 128x128 for the UI. Needless to say, I did not need write support for ico, since all of my source icons were in icns format. What I would've liked is Windows XP .ico writing support, but I couldn't find that (or sufficient docs to implement it) *anywhere* and I ended up using a commercial package on Win32 to do it in batch. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
