Code Management

[Jens]

On 21 Nov., 01:46, brzr... at gmail.com wrote:
> 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

Thank you very much for your ideas! I'm trying to make it work, and
have created a small example:

dummy/
  dummy_package/
    __init__.py
    moduleA.py
    tests/
       __init__.py
       test.py

I'm using Python 2.5.1. When I'm trying to call a function in
'moduleA' from 'test' it won't work unless I make the 'dummy' folder a
package as well. That's pretty weird. Does 'dummy_package' have to be
in my pythonpath or something? How do I reference moduleA from test?

I would like to avoid making 'dummy' into a package as well.