[Cython] Cython coverage and multiple projects
atash at google.com
Thu Oct 15 20:58:33 EDT 2015
Given that we have control over how and where source files get used by the
virtualenv, your suggestion seems within reach by doing a bit of
temporary-directory dancing. I've been hitting some issues with that
(unrelated to Cython as far as I can tell), and will attempt to update this
thread after digging.
Some more background: we'd been trying to avoid running tests directly
within the source directory and in a separate package to 'cleanly' capture
how a user of the library would see the code (from grabbing it e.g. on PyPI
to using it) and to keep the user free of the test modules on installation,
respectively. The ideals are gradually getting, uh, *influenced* by trying
to keep a variety of tools happy. It may be that the ideals simply aren't
meant to be (though certainly the separate-package reasoning may be
solvable via a host of other means, e.g. mucking around with the manifest
if the install->test reasoning is scrapped).
At the risk of bleeding frustration onto the page: a myriad of bugs,
'features', and such across multiple tools have turned this into an
exhausting grid search across axes among our desiderata (e.g. parallel test
execution), test tools, test setups, coverage setups, project organization,
test plugins, and varying degrees of separation of responsibility between
some of our shim scripts and the tools themselves. Certainly this is not a
problem originating from Cython, but I do wish there'd been some complete
blessed example project demonstrating the basic coverage+testing setup
along the way for Cython, possibly with some glue to e.g. py.test or
nosetests or nose2 or even a custom distutils/setuptools test command etc..
Thanks for the response!
On Sat, Oct 10, 2015 at 8:27 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Masood Malekghassemi via cython-devel schrieb am 08.10.2015 um 01:06:
> > I'm having trouble with getting Cython to play nicely with the
> > tool via the Cython.Coverage plug-in.
> > We have tests that are running from a different setup.py project than the
> > one which contains the Cython files (the projects respectively being for
> > the duration of this discussion the 'tests' project and the 'source'
> > project). The generated coverage file contains the line data for
> > .pyx files, but the paths of the .pyx files themselves *within* the
> > .coverage file appear to be rooted in the tests project rather than the
> > site-packages folder in which the source project's files were installed
> > (i.e. paths that never exist throughout the edit-build-test cycle).
> This seems to be a rather unusual setup. The "expected" setting is that
> tests live somewhere within the source checkout and are run on the
> non-installed sources, usually as part of the CI build process, sometimes
> even just as part of a separate reporting process. Why do you want to
> create coverage reports after the installation?
> > A secondary issue: the .pyx files are never copied over to the
> > directory, so even if the paths were 'correct' (with respect to being
> > copied into the site-packages folder or being accessible via developer
> > pip-installs), they wouldn't be found.
> Sure, that's a difference from .py/.pyc files which are getting executed
> directly. For Cython code, there is an additional compile/build step that
> generates the executable code from the sources, which are then no longer
> needed. That's another reason why support for coverage reporting after the
> installation seems foreign here and wouldn't be of much use.
> So, my suggestion would be to run the coverage reports within the source
> tree after building it, when all source files are readily available. But
> I'm obviously missing a lot of information about your actual project setup
> and the reasons behind what you are doing here.
> cython-devel mailing list
> cython-devel at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cython-devel