[Pythonmac-SIG] Drag and Drop Launch of whatever.py?

[Bob Ippolito]

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  
> pythonmac.org in
> the meantime (or have it be part of the main Python package).

easy_install is part of setuptools, so no, it's not going to be made  
into a mpkg. Distributing it with Python is not a bad idea  
necessarily, though.

-bob