[Distutils] A plan for scripts (in EasyInstall)

[Phillip J. Eby]

At 11:00 AM 6/6/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>Here's my semi-final plan for doing scripts with EasyInstall; please let 
>>me know if you see any issues with it:
>>* Make bdist_egg stick the scripts under an EGG-INFO/scripts/ 
>>subdirectory of the egg, by abusing the install_scripts command.  (Note: 
>>this does *not* mean they will be copied to 'PackageName.egg-info', only 
>>that they will be included in the built egg file.  Currently, 
>>subdirectories of .egg-info are not included in the built egg, so this is 
>>completely separate.)
>>* Add 'metadata_isdir' and 'metadata_listdir' APIs to pkg_resources, to 
>>allow inspecting the contents of EGG-INFO/scripts
>>* Add these options to the easy_install command:
>>    --exclude-scripts, -x     Don't install scripts
>>    --scripts-to=DIR, -t DIR  Install scripts to DIR
>
>Should these options match distutils?  Well, --install-scripts -- I don't 
>think it has an --exclude-scripts.  I don't really see a need for the 
>short form, but it doesn't really matter.

I could allow it as a synonym, I suppose, but since optparse lets you 
abbreviate longopts, I try to put as much distinction into the prefixes as 
possible.  With scripts-to, --scr is sufficient to uniquely identify it.


>>The downside to this assumption is that since the scripts are in the same 
>>place, they might become importable when that's not intended.  So if 
>>you're installing to a personal ~/lib/python, you will probably want to 
>>use -x or -t to override.
>
>How would they be importable?  Assuming you don't put __init__.py in 
>scripts/, it shouldn't be a problem, right?

Um, they'd be importable if the --install-dir is on sys.path, and they have 
.py extensions.


>All the fiddling with a fake __main__ module and whatnot seems 
>unnecessarily complicated,

It's not fake -- no more so than 'python -m' is.  The only thing faked 
anywhere in my final proposal is the script filename and linecache, and 
even those are only faked for zipped files, so that you can get a traceback 
that includes source.


>all to enable a crufty process.

Well, it is called *Easy*Install, after all, not "Might install future 
packages that are up to our newly-invented standards."  :)


>   In particular, I find __main__ annoying because of the double-import 
> problem (the same module existing as __main__ and as its true name) -- it 
> works okay for small utilities, but if I want to give the script any 
> polish at all I'd want to get rid of __main__.

Well-written packages do this today; their scripts will usually either just 
be a stub that imports main() from somewhere, or their "if 
__name__=='__main__'" block imports main from itself.  Such packages are 
not penalized by EasyInstall, and not-so-well-written packages won't be 
broken any more than they already are.

I think we should *also* have some kind of "new-style scripts" option, 
where you list metadata in your .egg-info directory or setup.py to describe 
what modules can be run as "main" modules, and whether they're console or 
GUI applications.  But, for EasyInstall the first priority is to support 
existing distutils scripts, for backward compatibility.  We can add the 
fancy new stuff afterwards, maybe in setuptools 0.5, which at the current 
rate of development should only be a couple of weeks from now.  ;)

(The things on my list for the 0.4.x releases are basic script support and 
automatic installation of a newly-installed package's dependencies.  In 
other words, a basically feature-complete package for end 
users.  Extensibility and developer-oriented features (like logging, and 
the ability to replace the standard URL opener with an app-specific one) 
will be in the 0.5.x series.)