<br><br><div class="gmail_quote">On Mon, Jul 20, 2009 at 14:50, Jesse Noller <span dir="ltr"><<a href="mailto:jnoller@gmail.com">jnoller@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Mon, Jul 20, 2009 at 5:38 PM, Paul Moore<<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
> 2009/7/20 Jesse Noller <<a href="mailto:jnoller@gmail.com">jnoller@gmail.com</a>>:<br>
>> So python -m "setuptools.commands.easy_install" <args> or python<br>
>> `which easy_install` is a-ok for people? I find it much easier to tell<br>
>> someone "run easy_install" or "run pylint" rather than either one of<br>
>> the previous examples.<br>
><br>
> No, but "python -m easy_install" is fine. The fact that setuptools<br>
> doesn't provide a form designed for use with python -m doesn't mean<br>
> that there's a problem with the feature, just that setuptools wasn't<br>
> designed with it in mind.<br>
><br>
> Paul.<br>
><br>
<br>
</div>I don't know if easy_install does or doesn't - I simply used it as an<br>
example. What I don't parse is that python -m <module> is somehow a<br>
replacement for ./script - the logic within a script can do a lot more<br>
than just firing off the __main__ of a module. Are we saying that<br>
"scripts are considered harmful" and recommend people only support -m<br>
for this?<br>
<br>
There's over 7000 packages, applications and libraries in the<br>
cheeseshop right now. A fair number of them would run face first into<br>
the non-versioned binary problem. I guess distutils (in a future<br>
version) should just deprecate the scripts/entry points options<br>
entirely?<br>
<br>
I really don't think this is an edge case, or should be unsupported.<br>
Sure, the same problem exists outside of the .local directory - you<br>
run into this installing things into the default system-level<br>
site-packages and /usr/bin /usr/local/bin directories, but there's no<br>
real reason we can't make this work better in the context of .local</blockquote><div><br></div><div>Taking Paul's follow-up email to this into account, I think we should definitely encourage people support runpy, but that doesn't do away with the usefulness of scripts. Ignoring the convenience factor of having short script names (``hg tip`` is much shorter than ``python2.6 -m mercurial -- tip``), there is also having to remember which interpreter you installed a tool under. Did I install hg under my Python 2.3, 2.4, 2.5 or 2.6 interpreter? I actually had to check the hg script to find that out.</div>

<div><br></div><div>And there is also the situation where people are not targeting multiple operating systems and thus have a use for the features a script gives. If I am writing some Linux app in Python I might have some need to run something under bash.</div>

<div><br></div><div>So while I totally support pushing people to start using runpy now that __main__.py support exists for packages, I don't think we can just fluff off script support.</div><div><br></div><div>-Brett</div>

</div>