<br><br><div class="gmail_quote">On Wed, Nov 23, 2011 at 6:05 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@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">No feedback at all on the prospect of changing the way we initialise</div>
sys.path[0] to respect the package information available on the<br>
filesystem?<br></blockquote><div><br></div><div>I gave you feedback previously: I think guessing based on __init__ files introduces new breakage potential at a distance for things that didn't break before. It'll also guess the wrong location when somebody bundles a dependency inside their package, and you try to run a script from the embedded package.</div>
<div><br></div><div>I've tried coming up with other ways to guess the right thing to do, but fundamentally, they're all just guessing.</div><div><br></div><div>What if we instead had something like this:</div><div>
<br></div><div> import sys</div><div> sys.set_script_module('foo.bar', __name__)</div><div><br></div><div>And what it did was, if __name__ is '__main__', and sys.path[0] is pointing to the parent directory of the script file, then it fixes sys.path[0] to point to the right parent directory level. (Sanity checking whether you can then find the __main__ module using the given module name and the resulting sys.path[0].)</div>
<div><br></div><div>Is it ugly? Yes. But it's *explicit*, and provides One Obvious Way to make a script that's also a module and will work correctly even if it's part of a package that's been embedded inside another package.</div>
<div><br></div><div>I think that this or some other form of explicit declaration is needed to get around __init__ ambiguities that exist in the field today.</div><div><br></div><div><br></div></div>