Exec with the Python binary of currently active virtualenv

[iqbalansari]

This pull requests updates pipdeptree to run itself with the Python binary of the currently active virtualenv. This should fix #2 and #11.

I have tested it on Python2.7 (Windows and Ubuntu 12.04, Ubuntu 16.04) and Python3.5 (Ubuntu 12.04, Ubuntu 16.04), I haven't written tests, would write them if you agree with the changes. I also think we will need a different strategy to test this change since this involves re-execing the currently running binary, your inputs on the same would be valuable.

[iqbalansari]

Not sure why the render PDF and render SVG tests are failing, will look into them

[iqbalansari]

I got a chance to look into the test failures, they are unrelated to my change. It seems they are failing because pipdeptree adds a newline to package labels while creating graphviz nodes, which in turn generates something like the following

digraph {
    Lookupy [label="Lookupy
             0.1"]
    redis [label="redis
           2.9.1"]
    ...
}

Add graphviz exits with a non-zero error code complaining about syntax error and a lot of warnings (not familiar with dot syntax but I think it is because of new-lines in the labels), here is the output from dot

Warning: test.dot:2: string ran past end of line Warning: test.dot:3: string ran past end of line Error: test.dot:4: syntax error near line 4 context: redis >>> [ <<< label="redis ... Warning: test.dot:50: string ran past end of line Warning: test.dot:51: string ran past end of line

Causing test failures, I tested after removing the newline and it seems to work great.

[naiquevin]

First of all this is great! Thanks for putting the effort.

I don't see any concerns with the approach, so you may proceed and add tests. IMO, mocking will simplify testing of this function. os.execv can be mocked to assert that it's being called with correct args on different platforms and with different cli args (we should also be able to mock sys.argv)

Besides this, one case I can think should be considered is when the virtualenv is created with a PYTHON_EXE (see the -p option of virtualenv) different from the system default. For eg. if the system wide default python is python2.7 and the virtualenv is created with python3.5. Now if system installed pipdeptree gets run in such a virtualenv, the reexec_in_virtualenv_maybe will run it with python3.5, whereas pipdeptree was originally installed for python2.7. This isn't a problem as long as both versions are supported but any issues arising because of this would be hard to debug. What do you think?

[iqbalansari]

Hi @naiquevin,

Really sorry for the delayed reply, was sort of busy with other things.

Besides this, one case I can think should be considered is when the virtualenv is created with a PYTHON_EXE (see the -p option of virtualenv) different from the system default.

Actually this did cause a bit of a issue especially when because the __file__ pointed to the compiled file in Python 2, to workaround that I explicitly strip the trailing 'c' if the __file__ has a pyc extension. It should not be a problem in later versions since __file__ always points to original file.

This isn't a problem as long as both versions are supported but any issues arising because of this would be hard to debug. What do you think?

Yes that is a valid issue, this was written with the assumption that pipdeptree would be compatible with both Python 2 and Python 3 (in fact the current workaround also depends on this) but I can see that this might get difficult to maintain. Do we have any other option?

I don't see any concerns with the approach, so you may proceed and add tests.

I will add some tests this weekend

Thanks

[gaborbernat]

Closing as this seems to have stalled.