> scripts = 
>    foo = a.b.c.main
>    foowin = a.b.c.winmain -window

This is great.  About -window: I don’t think using a fake option style (leading -) is useful, and I’d reuse the setuptools name, “gui”.  I also think this good idea of yours can solve our other feature requests:

unit2 = unittest2.main.main
unit2-tk = unittest2.gui.main window
spamd = spamlib.daemon.main sbin

The first example is a regular script; the second one will use pythonw on Windows and Mac OS X; the third one would install to /usr/sbin instead of /usr/bin on POSIX.  What do you think?

> 'scripts' belongs to the 'files' section in setup.cfg, it's still ok
> now to place it in 'files'?
As I said in private email, I don’t think it’s a concern at all, but maybe other people disagree.  An alternate idea: using a new section:

[scripts]
sphinx-build = sphinx.build.main

You should ask on the fellowship ML.

About setup.cfg and setup.py.  In general, packaging totally ignores setup.py.  However, one goal is to support generated setup.py that take all the info from the setup.cfg file, thanks to pysetup generate-setup.  In that case, there’s a compatibility question, as you said: what do we do with scripts as dotted paths?  It would be too much pain to use inspect.getsource to copy our functions that generate scripts into the setup.py file.  I think our documentation should just advise people to create an old-style script file and manually add it in their setup.py.

>> To support the old-style scripts generated by d*/s* in p*, we can use
>> the resource system.
> Not just as is, I believe. When scripts are installed (as opposed to
> other resources), it's not enough to copy them across to the
> configured destination: you also need to change their shebang lines
> to point to the appropriate Python executable.
That is true.  I see too possible solutions: tell people to use a hook, or have special handling for resources registered in the scripts category (IOW a built-in hook).  I prefer the second option.

> But how will we know which .py files mentioned in resources are data,
> and which are actually scripts?
Distutils scripts are not actually restricted to Python scripts.  The shebang updating only happens if a regex matches.  To answer your question: the resources system uses categories, one of which is “scripts”.

I’m -1 on using heuristics to handle both distutils-style files and packaging-style dotted paths (Vinay’s latest message).  It’s much cleaner to have separate fields or sections.

(BTW Vinay, remember that Roundup creates attachments when someone sends HTML email)