On Tue, Apr 27, 2010 at 00:00 +1000, meme dough wrote: > > I looked into the new plugin and have some immediate issues/questions: > > > > - ETOOMANYCMDLINEOPTIONS ... > > could most of the command line options go away > > if we rather rely on configurability through the config file? > > Yes/No, while more cmd options with -h that maybe take up more space, > it does give lots of control of coverage. I think this is good. It > could move some of them to config file only but I don't think it good > to remove completely. > > The good thing with pytest is the cmd options are auto done for > conftest and env var which you can see with the --help-config with no > work to do and consistent. Also all options have --cov prefix so > clear and no clash. > > If only downside is more output on -h then seems small con.
having around 10 options for one plugin makes it hard to know what the canonical usage is. And what happens if you have a mixed config-file/cmdline option situation? Also i doubt that e.g. being able to control output directories for html, xml, annotate needs to be that fine-grained, a '--cov-outputdir=...' is enough IMO. What about a generic --cov-option="...." that can be specified multiple times and can override config-ini values? This way you can (if you want to) still specify details on the command line but generally have a single place and way to specify config for coverage (in the ini file). > > - can you add basic (functional or unit) tests? > > Was early release with loose ends because people expressed an > interest, so can test drive and have look. > > I have tests but are simple compared to real project testing with. > Will commit when python versions issues are tidied up. > > > - is there a need to have a pytest_cov package instead of just a single > > module? > > Like this in preparation for rsync and activate plugin since better > rsync dir I think, but your other email I like better. For now just > require coverage / pytest-cov installed on slaves. But future have > slave env setup through normal python way (distutils2 and > virtualenv?). > > I will likely change to just module, but it seems more style thing so > not sure if matters too much either way it done. great, thanks for getting back on the issues. holger _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
