Re: [Pythonmac-SIG] Best way to do full-screen mode?
If you specify your screen setup for example
pygame.display.set_mode((1024,768), OPENGL|DOUBLEBUF|FULLSCREEN)
you can do all your drawing via OpenGL. And this works fine on a mac.
best,
Doug
Bob Ippolito wrote:
On Jul 21, 2006, at 3:39 PM, David Warde-Farley wrote:
On 21-Jul-06, at 6:26 PM, Robert Stephenson wrote:
My app needs a full-screen mode, and am looking for examples or
advice how to do it. CoreGraphics allows you to capture the
display and then draw on it, but since it's not written in ObjC my
understanding is that it's not easily accessible from PyObjC. An
alternative would be to bring up a borderless full-screen window.
Can that be done easily?
I know that Pygame can do this fairly easily on other platforms.
Given that it's all a wrapper on top of SDL it should work on the Mac
as well. (Can anyone confirm?)
Yes, pygame does work full screen, but you need to use SDL to draw in
that case.
That subset of CoreGraphics should be easy enough to talk to from
ctypes or PyObjC's FFI capability...
import objc
from Foundation import NSBundle
bndl = NSBundle.bundleWithPath_(objc.pathForFramework
('ApplicationServices.framework'))
# this is cheating, CGDirectDisplayID is a pointer, but we treat it
as an int
FUNCTIONS = [
('CGMainDisplayID', 'i'),
('CGDisplayCapture', 'ii'),
('CGDisplayRelease', 'ii'),
]
objc.loadBundleFunctions(bndl, globals(), FUNCTIONS)
Those functions should be all you need to jack into full-screen. With
ctypes it would be a bit different...
from ctypes import c_void_p, cdll, c_int
from ctypes.util import find_library
# again cheating, return value and arguments all default to int
# so we don't need to bother setting argtype/restype
_dylib = cdll.LoadLibrary(find_library('ApplicationServices'))
CGMainDisplayID = _dylib.CGMainDisplayID
CGDisplayCapture = _dylib.CGDisplayCapture
CGDisplayRelease = _dylib.CGDisplayRelease
-bob
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ANN] py2app 0.3.2
On Jul 21, 2006, at 5:25 PM, Dethe Elza wrote: > Kaweh Kazemi wrote: >> essentially i am trying to package a Panda3D test application using >> py2app - see http://knuddl.net/moin.cgi/InstallPanda3d for my Panda3D >> package if interested(compiled/linked for OS X including installation >> instructions) - though be aware that the installation is still >> cumbersome and definitely not as user friendly as i would like it to >> be - this is still very experimental (Panda3D has no official OS X >> support yet); anyways, i'll re-link the libraries and see how it's >> going. >> >> thanks, >> kaweh > > I, for one, am excited to see Panda3D coming to the Mac. I have tried > (and failed) to install it before. Before I dive in this time I > have a > couple of questions. > > 1) Is your version working on Intel Macs (I have a Macbook Pro). It'd probably work if it was built on i386, but the instructions say to build some of the dependencies w/ DarwinPorts, so the final product is going to be dependent on a particular architecture. DarwinPorts doesn't built things universally. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ANN] py2app 0.3.2
Kaweh Kazemi wrote: > essentially i am trying to package a Panda3D test application using > py2app - see http://knuddl.net/moin.cgi/InstallPanda3d for my Panda3D > package if interested(compiled/linked for OS X including installation > instructions) - though be aware that the installation is still > cumbersome and definitely not as user friendly as i would like it to > be - this is still very experimental (Panda3D has no official OS X > support yet); anyways, i'll re-link the libraries and see how it's > going. > > thanks, > kaweh I, for one, am excited to see Panda3D coming to the Mac. I have tried (and failed) to install it before. Before I dive in this time I have a couple of questions. 1) Is your version working on Intel Macs (I have a Macbook Pro). 2) Your instructions include the Nvidia Cg toolkit, but I have an ATI Radeon X1600. Should I skip that step, or does that mean I'm out of luck for the time begin? Thanks for working on this! --Dethe ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Best way to do full-screen mode?
On Jul 21, 2006, at 3:39 PM, David Warde-Farley wrote:
> On 21-Jul-06, at 6:26 PM, Robert Stephenson wrote:
>
>> My app needs a full-screen mode, and am looking for examples or
>> advice how to do it. CoreGraphics allows you to capture the
>> display and then draw on it, but since it's not written in ObjC my
>> understanding is that it's not easily accessible from PyObjC. An
>> alternative would be to bring up a borderless full-screen window.
>> Can that be done easily?
>
> I know that Pygame can do this fairly easily on other platforms.
> Given that it's all a wrapper on top of SDL it should work on the Mac
> as well. (Can anyone confirm?)
Yes, pygame does work full screen, but you need to use SDL to draw in
that case.
That subset of CoreGraphics should be easy enough to talk to from
ctypes or PyObjC's FFI capability...
import objc
from Foundation import NSBundle
bndl = NSBundle.bundleWithPath_(objc.pathForFramework
('ApplicationServices.framework'))
# this is cheating, CGDirectDisplayID is a pointer, but we treat it
as an int
FUNCTIONS = [
('CGMainDisplayID', 'i'),
('CGDisplayCapture', 'ii'),
('CGDisplayRelease', 'ii'),
]
objc.loadBundleFunctions(bndl, globals(), FUNCTIONS)
Those functions should be all you need to jack into full-screen. With
ctypes it would be a bit different...
from ctypes import c_void_p, cdll, c_int
from ctypes.util import find_library
# again cheating, return value and arguments all default to int
# so we don't need to bother setting argtype/restype
_dylib = cdll.LoadLibrary(find_library('ApplicationServices'))
CGMainDisplayID = _dylib.CGMainDisplayID
CGDisplayCapture = _dylib.CGDisplayCapture
CGDisplayRelease = _dylib.CGDisplayRelease
-bob
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Best way to do full-screen mode?
On 21-Jul-06, at 6:26 PM, Robert Stephenson wrote: > My app needs a full-screen mode, and am looking for examples or > advice how to do it. CoreGraphics allows you to capture the > display and then draw on it, but since it's not written in ObjC my > understanding is that it's not easily accessible from PyObjC. An > alternative would be to bring up a borderless full-screen window. > Can that be done easily? I know that Pygame can do this fairly easily on other platforms. Given that it's all a wrapper on top of SDL it should work on the Mac as well. (Can anyone confirm?) Dave ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Best way to do full-screen mode?
My app needs a full-screen mode, and am looking for examples or advice how to do it. CoreGraphics allows you to capture the display and then draw on it, but since it's not written in ObjC my understanding is that it's not easily accessible from PyObjC. An alternative would be to bring up a borderless full-screen window. Can that be done easily?- Rob * * * * * * * * * * * * * * * * * * * * * * ** Dr. Robert S. Stephenson* E-learning Architect* [EMAIL PROTECTED]* (415) 341-3784* http://sun.science.wayne.edu/~rstephe** Community Manager* Global Education & Learning Community on Java.net* http://gelc.org** Chief Architect and Principal Investigator* http://OpenCourse.Org* Supporting virtual communities of e-learning developers.** Founder* The Harvey Project* Open Course Physiology on the Web* http://HarveyProject.org** Was I helpful? Let others know:* http://rate.affero.net/rstephe** gpg key fingerprint:* 4255 FB43 17C8 2B80 8074 7DB6 7DD7 939B F3F6 CB92* * * * * * * * * * * * * * * * * * * * * * * ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ANN] py2app 0.3.2
>> WARNING: Mach-O header may be too large to relocate >> Traceback (most recent call last): >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/py2app-0.3.2-py2.4.egg/py2app/build_app.py", >> line 548, in _run >> self.run_normal() >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/py2app-0.3.2-py2.4.egg/py2app/build_app.py", >> line 619, in run_normal >> self.create_binaries(py_files, pkgdirs, extensions, >> loader_files) >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/py2app-0.3.2-py2.4.egg/py2app/build_app.py", >> line 732, in create_binaries >> platfiles = mm.run() >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/ >> MachOStandalone.py", line 135, in run >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py", >> line 111, in write >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py", >> line 302, in write >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py", >> line 292, in synchronize_size >> ValueError: New Mach-O header is too large to relocate >>> /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ >> site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py(292) >> synchronize_size() >> >> >> i'm trying to include a custom made library into my application. i'm >> not assuming that py2app (or macholib) is the problem here, but the >> library, though i was hoping that this error-message could give >> someone a clue where i could look to solve my problem. >> >> any hints are much appreciated. > > Some Mach-O don't have enough room leftover to rewrite their load > commands. This is quite rare, but you may have to re-link the > library with -headerpad_max_install_names. It could otherwise be a > bug in macholib, but I wouldn't be able to say without a copy of > the library. thanks a lot. i will give that a try and re-link the libraries. essentially i am trying to package a Panda3D test application using py2app - see http://knuddl.net/moin.cgi/InstallPanda3d for my Panda3D package if interested(compiled/linked for OS X including installation instructions) - though be aware that the installation is still cumbersome and definitely not as user friendly as i would like it to be - this is still very experimental (Panda3D has no official OS X support yet); anyways, i'll re-link the libraries and see how it's going. thanks, kaweh ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ANN] py2app 0.3.2
>> WARNING: Mach-O header may be too large to relocate >> Traceback (most recent call last): >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/py2app-0.3.2-py2.4.egg/py2app/build_app.py", >> line 548, in _run >> self.run_normal() >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/py2app-0.3.2-py2.4.egg/py2app/build_app.py", >> line 619, in run_normal >> self.create_binaries(py_files, pkgdirs, extensions, >> loader_files) >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/py2app-0.3.2-py2.4.egg/py2app/build_app.py", >> line 732, in create_binaries >> platfiles = mm.run() >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/ >> MachOStandalone.py", line 135, in run >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py", >> line 111, in write >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py", >> line 302, in write >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py", >> line 292, in synchronize_size >> ValueError: New Mach-O header is too large to relocate >>> /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ >> site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py(292) >> synchronize_size() >> >> >> i'm trying to include a custom made library into my application. i'm >> not assuming that py2app (or macholib) is the problem here, but the >> library, though i was hoping that this error-message could give >> someone a clue where i could look to solve my problem. >> >> any hints are much appreciated. > > Some Mach-O don't have enough room leftover to rewrite their load > commands. This is quite rare, but you may have to re-link the > library with -headerpad_max_install_names. It could otherwise be a > bug in macholib, but I wouldn't be able to say without a copy of > the library. thanks a lot. i will give that a try and re-link the libraries. essentially i am trying to package a Panda3D test application using py2app - see http://knuddl.net/moin.cgi/InstallPanda3d for my Panda3D package if interested(compiled/linked for OS X including installation instructions) - though be aware that the installation is still cumbersome and definitely not as user friendly as i would like it to be - this is still very experimental (Panda3D has no official OS X support yet); anyways, i'll re-link the libraries and see how it's going. thanks, kaweh ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ANN] py2app 0.3.2
>> WARNING: Mach-O header may be too large to relocate >> Traceback (most recent call last): >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/py2app-0.3.2-py2.4.egg/py2app/build_app.py", >> line 548, in _run >> self.run_normal() >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/py2app-0.3.2-py2.4.egg/py2app/build_app.py", >> line 619, in run_normal >> self.create_binaries(py_files, pkgdirs, extensions, >> loader_files) >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/py2app-0.3.2-py2.4.egg/py2app/build_app.py", >> line 732, in create_binaries >> platfiles = mm.run() >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/ >> MachOStandalone.py", line 135, in run >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py", >> line 111, in write >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py", >> line 302, in write >>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py", >> line 292, in synchronize_size >> ValueError: New Mach-O header is too large to relocate >>> /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ >> site-packages/macholib-1.1-py2.4.egg/macholib/MachO.py(292) >> synchronize_size() >> >> >> i'm trying to include a custom made library into my application. i'm >> not assuming that py2app (or macholib) is the problem here, but the >> library, though i was hoping that this error-message could give >> someone a clue where i could look to solve my problem. >> >> any hints are much appreciated. > > Some Mach-O don't have enough room leftover to rewrite their load > commands. This is quite rare, but you may have to re-link the > library with -headerpad_max_install_names. It could otherwise be a > bug in macholib, but I wouldn't be able to say without a copy of > the library. thanks a lot. i will give that a try and re-link the libraries. essentially i am trying to package a Panda3D test application using py2app - see http://knuddl.net/moin.cgi/InstallPanda3d for my Panda3D package if interested(compiled/linked for OS X including installation instructions) - though be aware that the installation is still cumbersome and definitely not as user friendly as i would like it to be - this is still very experimental (Panda3D has no official OS X support yet); anyways, i'll re-link the libraries and see how it's going. thanks, kaweh ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ANN] py2app 0.3.2
On Jul 21, 2006, at 3:09 PM, Kaweh Kazemi wrote:
>>> changing the path order would be a problem (at least for me),
>>> wouldn't it?
>>>
>>> my python2.4 (and the approriate link 'python') is in /usr/local/bin
>>> (as installed with the latest Python Universal installer if i recall
>>> correctly) and if i type 'python' into the terminal i would like
>>> this
>>> version to be picked up and not the apple version in /usr/bin -
>>> which
>>> is python2.3 (and the link 'python' to it). i'm just confused if my
>>> setup is not correct, but anyways it works for me, so i believe i
>>> should be fine.
>>
>> No. /usr/local/bin/python* is only there for backwards
>> compatibility with what previous installers did. The installer
>> also adds this to your .profile:
>>
>> # Setting PATH for MacPython 2.4
>> # The orginal version is saved in .profile.pysave
>> PATH="/Library/Frameworks/Python.framework/Versions/Current/bin:$
>> {PATH}"
>>
>> This directory has the actual python binaries, and this is where
>> distutils/setuptools install scripts to.
>
> thanks for the clarification and your time, bob.
>
> i was using .bash_profile which seemed to override .profile (sorry,
> i'm not really a bash expert and that setup did work for me). i've
> fixed that in my environment now and i'm using .profile for my stuff.
We should probably add some more smarts to the installer to
detect .bash_profile as well.
>> No. /usr/local/bin/python* is only there for backwards
>> compatibility with what previous installers did. The installer
>> also adds this to your .profile:
>>
>
> is it safe to remove /usr/local/bin/python* then or should the
> stuff remain there? just curious.
Should be safe to remove if you really want to.
-bob
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ANN] py2app 0.3.2
>> changing the path order would be a problem (at least for me),
>> wouldn't it?
>>
>> my python2.4 (and the approriate link 'python') is in /usr/local/bin
>> (as installed with the latest Python Universal installer if i recall
>> correctly) and if i type 'python' into the terminal i would like this
>> version to be picked up and not the apple version in /usr/bin - which
>> is python2.3 (and the link 'python' to it). i'm just confused if my
>> setup is not correct, but anyways it works for me, so i believe i
>> should be fine.
>
> No. /usr/local/bin/python* is only there for backwards
> compatibility with what previous installers did. The installer also
> adds this to your .profile:
>
> # Setting PATH for MacPython 2.4
> # The orginal version is saved in .profile.pysave
> PATH="/Library/Frameworks/Python.framework/Versions/Current/bin:$
> {PATH}"
>
> This directory has the actual python binaries, and this is where
> distutils/setuptools install scripts to.
thanks for the clarification and your time, bob.
i was using .bash_profile which seemed to override .profile (sorry,
i'm not really a bash expert and that setup did work for me). i've
fixed that in my environment now and i'm using .profile for my stuff.
> No. /usr/local/bin/python* is only there for backwards
> compatibility with what previous installers did. The installer also
> adds this to your .profile:
>
is it safe to remove /usr/local/bin/python* then or should the stuff
remain there? just curious.
thanks again,
kaweh
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Drag and Drop Launch of whatever.py?
On Jul 21, 2006, at 12:03 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> On Jul 20, 2006, at 5:11 PM, Christopher Barker wrote: >>> Again, I see the need for py2app to be able to create "applets" -- > >> What exactly are applets supposed to be anyway? I'm not sure what >> you'd >> want that isn't already covered by py2app... > > I wrote that because I remembered that you once specifically said that > you didn't see the need for it, and thus wouldn't write the code to do > it. so i figured someone else had to write it. > >> --alias covers the "well I already have *all* the files installed" >> case > > This may be what I'm looking for. > >> --semi-standalone covers the "depend on installed Python" case > > I don't think I want this, as I thought it only worked with Apple's > Python. You've got it backwards, Apple's Python only works with --semi- standalone. Using a vendor Python implies --semi-standalone. The option is applicable to any installation. >> --site-packages covers the "depend on some third party stuff being >> installed" case >> >> The only caveat I guess is the latter case, because you will have to >> explicitly set up a list of third party packages in your excludes. > > That may be perfect. > > I'll give them a try. > > Sorry to ask about something i could have found out myself. --site-packages implies --semi-standalone too, of course. It doesn't make any sense to embed Python, but use the site-packages folder from another Python installation. >>> By the way, Bob, thanks for the new py2App, it seems to be >>> working well. >>> Is there a way to get it (and setuptools) in?: >>> >>> pythonmac.org/packages >> >> No, and I already answered that (twice-ish): >> >> http://mail.python.org/pipermail/pythonmac-sig/2006-July/017836.html >> http://mail.python.org/pipermail/pythonmac-sig/2006-July/017839.html > > Right, you did answer the setuptools question. As for putting Py2app > there, you made it clear why I couldn't make a mpkg, but I didn't' > think > that meant it was impossible. Anything is possible, but that doesn't mean it should be done. > From the first post: > > """ > setuptools should be installed > using its own means so it can properly upgrade itself. bdist_mpkg > packages aren't really compatible with eggs > """ > > This is a problem. When we all had that that big "What should the > 'official' python be on OS-X" discussion a while back, it seems there > was a consensus that it would be good to have one supported python, > and > one supported repository of packages for it. Also that it should be as > "point and clicky" as possible. That's what the repository at > pythonmac.org is, and I think that it's a good start, now that we > have a > useful number of packages there, and I've been doing my tiny bit by > contributing what I can. > > However, Py2App is a critical component, and it's really too bad to > not > have a way to make it available the same way. mpkg's have always been suboptimal. eggs solve most of the problems with packaging and installation, and setuptools is at a stage of maturity and adoption that it's an option. It's also cross-platform knowledge, I can type "easy_install simplejson" on FreeBSD, Linux, Mac OS X, Windows, etc. and expect the right thing to happen. As a developer, my installation documentation can be simply "install setuptools, then type easy_install PackageName". Installer only has one useful feature (excluding GUI and bootstrapping issues) that eggs/easy_install does not: the ability to install extra junk. This isn't used by many packages, but pygame as currently distributed absolutely requires the frameworks to be installed. This is probably best fixed by extending easy_install/ setuptools to support that use case somehow. > In part of that conversation, it was proposed that it would be good to > have a GUI tool that was a front end to setuptools: i.e. something > that > would come up when you clicked on an .egg. I suppose once we did that, > we could go to having .eggs, rather than .mpkgs as the standard > way to > distribute modules on Python. Why not just teach people how to type a command or two into the Terminal? They're going to need to learn at some point anyway. It's easier than wishing really hard that we had a GUI. I'm not really interested in writing one; I'd absolutely never use it unless it provided functionality above and beyond easy_install, but that effort would be better spent improving the setuptools stack for all platforms. I don't find easy_install to be at all daunting. All you have to do is give it the name of the app, a URL, or a path on disk and it does its thing. If you specify -U it makes sure your version is up to date. What's the big deal? A front-end would be a huge amount of work to do properly, and improperly it'd be a stupid way of typing "easy_install somepackage" for you. > Maybe we could at least have a mpkg for easy_install on
Re: [Pythonmac-SIG] Drag and Drop Launch of whatever.py?
Bob Ippolito wrote: > On Jul 20, 2006, at 5:11 PM, Christopher Barker wrote: >> Again, I see the need for py2app to be able to create "applets" -- > What exactly are applets supposed to be anyway? I'm not sure what you'd > want that isn't already covered by py2app... I wrote that because I remembered that you once specifically said that you didn't see the need for it, and thus wouldn't write the code to do it. so i figured someone else had to write it. > --alias covers the "well I already have *all* the files installed" case This may be what I'm looking for. > --semi-standalone covers the "depend on installed Python" case I don't think I want this, as I thought it only worked with Apple's Python. > --site-packages covers the "depend on some third party stuff being > installed" case > > The only caveat I guess is the latter case, because you will have to > explicitly set up a list of third party packages in your excludes. That may be perfect. I'll give them a try. Sorry to ask about something i could have found out myself. >> By the way, Bob, thanks for the new py2App, it seems to be working well. >> Is there a way to get it (and setuptools) in?: >> >> pythonmac.org/packages > > No, and I already answered that (twice-ish): > > http://mail.python.org/pipermail/pythonmac-sig/2006-July/017836.html > http://mail.python.org/pipermail/pythonmac-sig/2006-July/017839.html Right, you did answer the setuptools question. As for putting Py2app there, you made it clear why I couldn't make a mpkg, but I didn't' think that meant it was impossible. From the first post: """ setuptools should be installed using its own means so it can properly upgrade itself. bdist_mpkg packages aren't really compatible with eggs """ This is a problem. When we all had that that big "What should the 'official' python be on OS-X" discussion a while back, it seems there was a consensus that it would be good to have one supported python, and one supported repository of packages for it. Also that it should be as "point and clicky" as possible. That's what the repository at pythonmac.org is, and I think that it's a good start, now that we have a useful number of packages there, and I've been doing my tiny bit by contributing what I can. However, Py2App is a critical component, and it's really too bad to not have a way to make it available the same way. In part of that conversation, it was proposed that it would be good to have a GUI tool that was a front end to setuptools: i.e. something that would come up when you clicked on an .egg. I suppose once we did that, we could go to having .eggs, rather than .mpkgs as the standard way to distribute modules on Python. Of course, none of that happens until someone that knows what they are doing, and has the time, writes the code. it would be nice to have a goal in mind, however. Maybe we could at least have a mpkg for easy_install on pythonmac.org in the meantime (or have it be part of the main Python package). -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
