title: Deploying a python application with shared package
body: <p>I'm thinking how to arrange a deployed python application which will have a </p>
  
  <ol>
  <li>Executable script located in /usr/bin/ which will provide a CLI to functionality implemented in</li>
  <li>A library installed to wherever the current site-packages directory is.</li>
  </ol>
  
  <p>Now, currently, I have the following directory structure in my sources:</p>
  
  <pre><code>foo.py
  foo/
    __init__.py
    ...
  </code></pre>
  
  <p>which I guess is not the best way to do things. During development, everything works as expected, however when deployed, the "from foo import FooObject" code in foo.py seemingly attempts to import foo.py itself, which is not the behaviour I'm looking for.</p>
  
  <p>So the question is what is the standard practice of orchestrating situations like this? One of the things I could think of is, when installing, rename foo.py to just foo, which stops it from importing itself, but that seems rather awkward...</p>
  
  <p>Another part of the problem, I suppose, is that it's a naming challenge. Perhaps call the executable script foo-bin.py?</p>