Code Management

[Jens]

On 21 Nov., 04:16, Jens <j3n... at gmail.com> wrote:
> 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.

Problem solved. I added 'dummy' to the PYTHONPATH. (Do I really have
to do that for every project I create?) Anyway, it works the way I'd
like it to now.