cmdline.py overwrites first sys.path entry

[fschulze]

In the command_line method there is sys.path[0] = ''. I guess this works most of the time, because coverage is the first entry in many scenarios. There are cases where this isn't true though, for example with zc.buildout. I guess it would be better to do sys.path.insert(0, ''), but I'm unsure about further implications of that.

[nedbat]

Can you provide some details about what is going wrong? What is the first entry originally, and what bad thing happens because of coverage? How are you running coverage, and can you provide a reproducible scenario?

[fschulze]

I'm trying to develop a plugin for coverage. I do that in an existing project which uses zc.buildout. It generates a script like this for coverage:

#!/Users/fschulze/Development/project/bin/python2.7

import sys
sys.path[0:0] = [
  '/Users/fschulze/Development/project/src/chameleon_coverage_plugin',
  '/Users/fschulze/Development/project/eggs/coverage-4.5.1-py2.7-macosx-10.13-x86_64.egg',
  ]

import coverage.cmdline

if __name__ == '__main__':
    sys.exit(coverage.cmdline.main())

Normally coverage is the first entry and setting it to '' doesn't matter, because coverage is already imported. But because the plugin is placed first by buildout, the path to it is overwritten and coverage can't load the plugin.

[nedbat]

@fschulze Normally, the plugin is found by installing it so that it is importable, and then naming the importable module name in the .coveragerc file. Are you doing something different?

[fschulze]

As I said, I'm using zc.buildout. I've made a gist to reproduce: https://gist.github.com/fschulze/fce8a15ca8cc615443fc70bb5f16595c

[fschulze]

The generated coverage script looks like this:

#!/Users/fschulze/temp/coverage/bin/python2.7

import sys
sys.path[0:0] = [
  '/Users/fschulze/temp/coverage/src/chameleon_coverage_plugin',
  '/Users/fschulze/temp/coverage/eggs/coverage-4.5.1-py2.7-macosx-10.13-x86_64.egg',
  ]

import coverage.cmdline

if __name__ == '__main__':
    sys.exit(coverage.cmdline.main())

[fschulze]

I've just checked what the sys.path looks like in a virtualenv:

['/Users/fschulze/temp/coverage/bin', '/Users/fschulze/temp/coverage/lib/python36.zip', '/Users/fschulze/temp/coverage/lib/python3.6', '/Users/fschulze/temp/coverage/lib/python3.6/lib-dynload', '/Users/fschulze/.pyenv/versions/3.6.5/lib/python3.6', '/Users/fschulze/temp/coverage/lib/python3.6/site-packages']

Here it works, because no one places Python packages in bin for import.

[nedbat]

#715 is a dup of this, with more discussion. @fschulze Would it work for you to just remove the sys.path modification line?

[fschulze]

@nedbat I have to test that, but I'm pretty sure it will

[fschulze]

@nedbat yes, removing that line fixes it for me

[nedbat]

@fschulze Is it true that the only import problem is coverage trying to import your plugin? Can you tell me more about the plugin (just curious), and how you are configured to find it?

[fschulze]

Yes, it's true, because of the way buildout sets up sys.path:

#!/Users/fschulze/temp/coverage/bin/python2.7

import sys
sys.path[0:0] = [
  '/Users/fschulze/temp/coverage/src/chameleon_coverage_plugin',
  '/Users/fschulze/temp/coverage/eggs/coverage-4.5.1-py2.7-macosx-10.13-x86_64.egg',
  ]

import coverage.cmdline

if __name__ == '__main__':
    sys.exit(coverage.cmdline.main())

The first entry would then be set to the empty string by coverage causing the import failure.

[nedbat]

This is re-fixed in commit b7e0eec, released as part of 5.0a4.

[fschulze]

5.0a4 works for me, thanks!