Code Management

[brzrkr0 at gmail.com]

On Nov 20, 4:09 pm, Jens <j3n... at gmail.com> wrote:
> Dear Reader,
>
> I'm writing some modules in Python, and I'm also using unittests. I'm
> wondering about some things:

I'd love to hear how others manage this sort of thing as well.  I'll
describe what I've found works best for me, and if others do the same,
maybe we can all learn from each other.

> 1) Should I put my unittests in a subdirectory? Does the subdirectory
> have to be a package?

I put them in a subdirectory and make it a package.  The biggest
advantage I see of using a subdirectory is that I can have lots of
test scripts and it's easy to keep them organized separately from
production code.  The biggest disadvantage is that if I run the test
scripts from inside that subdirectory, they need to import modules
from their parent directory, and I'm using Python 2.4 which doesn't
have relative imports.  So I put a .pth file in my site-packages
directory that adds the top-level package of my project to the
pythonpath.  Then the test modules can import production code using
the fully qualified package.subpackage.module name for each production
module being tested.

> 2) Does the main folder /myproject have to be a package? Should I put
> my modules directly under /myproject, or should I create a subfolder,
> for example /myproject/modules

I make all non-trivial projects into packages.  It allows me to do the
trick with a .pth file I described above.  It makes it easier to reuse
all or part of my project as a component of a second project.  And  it
makes creating documentation with epydoc easier.

I typically lay out a project directory something like this:

projectname/
  setup.py
  dev_install.py # automatically creates .pth file in site-packages
  alltests.py # runs all unit tests
  main_package_name/
    __init__.py
    module1.py
    module2.py
    doc/
    img/
    subpackage1/
      __init__.py
      module3.py
      module4.py
      tests/
        __init__.py
        test1.py
        test2.py
    subpackage2/
      etc....

With this setup, tests are organized by subpackage, and each test
script can be run by itself, or all together from alltests.py.  If a
module in subpackage2 needs to import a module from subpackage1
(generally a sign of poor design, but it happens), it would need to
use the fully qualified "import
main_package_name.subpackage1.module1".  Each time I check a new copy
of the project out from version control to a new location, I have to
make that the "active" version by running dev_install.py, which puts
a .pth file in site-packages that adds the newly checked out path to
the pythonpath.  As long as I remember that step, this approach works
well.

> Does anyone have any "best practices" as to how to manage your code?
>
> Thanks!

If anyone does, I'd love to hear about them.

-Casey Raymondson