* Ben Finney [2008-08-22 08:21 +0200]:
On 22-Aug-2008, Nicolas Évrard wrote:
* Ben Finney [2008-08-22 01:25 +0200]:
On 21-Aug-2008, Nicolas Évrard wrote:
    % nosetests --cover-erase --with-coverage --cover-package=relatorio

And it shows the following table after the tests has runned:

    Name                               Stmts   Exec  Cover   Missing
    ----------------------------------------------------------------
relatorio 3 3 100% relatorio.reporting 78 0 0% 21-146
    relatorio.templates                   11      0     0%   21-39
    relatorio.templates.chart             48      0     0%   21-93
    relatorio.templates.opendocument     212      0     0%   21-331
    relatorio.templates.pdf               44      0     0%   21-86
    ----------------------------------------------------------------
TOTAL 396 3 0%

I believe python-coverage is behaving correctly in this case. Python doesn't care whether a module is actually a symlink on disk; different module files are different files. Indeed, modules should be implemented so that they work whether or not the filesystem supports symlinks. Python's namespace support makes this easy.

Well while developping I often replace the module in my $HOME/python by a symlink to the directory where I am working so I do not use the symlink to have code accessible through two different namespaces. So here's my setup:

    $PYTHONPATH=.:$HOME/python
    % ls $HOME/python
    relatorio -> wherever the developpment version is

I don't understand, then. Which of the above modules are duplicates, under your setup? Where are the actual files? What is symlinking to what?

The relatorio module in my $HOME/python is a symlink to the dev version residing in $HOME/projets/relatorio/oh-branch.

Thus, import relatorio imports the dev version (because I replaceed the stable version by a link to the mercurial repository). relatorio.__file__ is returning the filename useing $HOME/python but when developping I am in $HOME/projets/relatorio/oh-branch and then since python-coverages is probably doing a os.getcwd it does not recognize that I am invoking it on the same file (Thus a patch would be to store the coverage data with the real path instead of using the symlink path, If I'm right I'll try to do that).

OTH, thanks.

--
(°>  Nicolas Évrard
/ )  Liège - Belgique
^^



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to