j3nsby at gmail.com
Wed Nov 21 04:49:18 CET 2007
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:
> 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.
More information about the Python-list