On 21 Nov., 01:46, [EMAIL PROTECTED] wrote:
> On Nov 20, 4:09 pm, Jens <[EMAIL PROTECTED]> 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.
--
http://mail.python.org/mailman/listinfo/python-list
