Bug#495963: python-coverage: code coverage shows 0% cover on linked files
package python-coverage tags 495963 + upstream pending thanks On 25-Aug-2008, Nicolas Évrard wrote: --- coverage.py 2008-08-25 08:46:53.0 +0200 +++ coverage.py.old 2008-08-25 08:46:24.0 +0200 @@ -534,7 +534,7 @@ if os.path.exists(g): f = g break -cf = os.path.normcase(os.path.realpath(os.path.abspath(f))) +cf = os.path.normcase(os.path.abspath(f)) self.canonical_filename_cache[filename] = cf return self.canonical_filename_cache[filename] Upstream version 2.85 has applied a very similar change URL:http://nedbatchelder.com/code/modules/coverage.html#h_Version_2.85_2C_September_14_2008 which will fix this bug when that version is packaged for Debian. -- \ “Dare to be naïve.” —Richard Buckminster Fuller, personal motto | `\ | _o__) | Ben Finney [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#495963: python-coverage: code coverage shows 0% cover on linked files
* Ben Finney [2008-08-22 08:21 +0200]: Tags: patch 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 TOTAL396 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? Here is a patch for this issue, that fixes the problem I am encountering. -- (° Nicolas Évrard / ) Liège - Belgique ^^ --- coverage.py 2008-08-25 08:46:53.0 +0200 +++ coverage.py.old 2008-08-25 08:46:24.0 +0200 @@ -534,7 +534,7 @@ if os.path.exists(g): f = g break -cf = os.path.normcase(os.path.realpath(os.path.abspath(f))) +cf = os.path.normcase(os.path.abspath(f)) self.canonical_filename_cache[filename] = cf return self.canonical_filename_cache[filename]
Bug#495963: python-coverage: code coverage shows 0% cover on linked files
* 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 TOTAL396 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]
Bug#495963: python-coverage: code coverage shows 0% cover on linked files
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 TOTAL396 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? -- \“Every sentence I utter must be understood not as an | `\ affirmation, but as a question.” —Niels Bohr | _o__) | Ben Finney [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#495963: python-coverage: code coverage shows 0% cover on linked files
Package: python-coverage Version: 0.10.3-1 Severity: normal Hello, I tried to use nosetest with the test coverage. So I used it on my project: relatorio (http://relatorio.openhex.org). With the following command: % 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 TOTAL396 3 0% python-coverage -r templates/opendocument.py show the same figures but when using python-coverage -r /home/nicoe/python/relatorio-0.1.1-py2.5.egg/relatorio/templates/opendocument.py It works but those are the same files since the second one is a link to the real file. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-nose depends on: ii python2.5.2-2An interactive high-level object-o ii python-pkg-resources 0.6c8-4Package Discovery and Resource Acc ii python-support0.8.5 automated rebuilding support for P python-nose recommends no packages. Versions of packages python-nose suggests: ii python-coverage 2.80-1 code coverage tool for Python -- no debconf information -- Nicolas Évrard | Web: http://www.openhex.com Liège - Belgique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495963: python-coverage: code coverage shows 0% cover on linked files
package reportbug severity 495963 wishlist retitle 495963 python-coverage: show same coverage for symlink files as their target thanks 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 TOTAL396 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. The usual way to have 'relatorio.bar.foo.spam' be the same as 'relatorio.foo.spam' is not to have the module file appear multiple times on the filesystem, but instead to import one namespace into another: = relatorio/bar/__init__.py = = = relatorio/bar/foo.py = spam = Spam = = relatorio/__init__.py = from bar import foo = That way, 'spam', which was only defined in one module file, will be accessible both as 'relatorio.bar.foo.spam' and 'relatorio.foo.spam'. = import relatorio relatorio.foo.spam is relatorio.bar.foo.spam True = No symlinks are required, and your modules will continue to work the same when implemented on a system without symlink support. Based on this, I don't think this is a use case for which python-coverage should be adapted. I'm intending to mark this report wontfix. -- \ “Military justice is to justice what military music is to | `\ music.” —Groucho Marx | _o__) | Ben Finney [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#495963: python-coverage: code coverage shows 0% cover on linked files
* 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 TOTAL396 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 So it is precisely because python does not care if the module is a symlink or a real directory that python-coverage should consider those file as the same. Based on this, I don't think this is a use case for which python-coverage should be adapted. I'm intending to mark this report wontfix. Well I don't think so (but I agree that I should have used wishlist but I forgot to change it in the vim buffer). Anyway thank you for your time. -- (° Nicolas Évrard / ) Liège - Belgique ^^ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
