Don't launch subprocess for pip_deepfreeze

[Bobronium]

Since it's just a python lib, it should be possible to just import it and use its entrypoint to perform needed actions.
This will benefit the speed, since there's not going to be the whole new interpreted startup needed, and pip_freeze will reuse already imported modules in current interpreter process.

I'm willing to make a PR if you find this desired and don't see potential shortcomings of suggested approach.

[sbidoul]

Before doing a PR here, we would first need to expose and document a stable public api in pip-deepfreeze.

That might be interesting but first we should check that it significantly improves performance.

Indeed, by design, pip-deepfreeze does several pip subprocess calls, so the pip-deepfreeze subprocess invocation time may be dwarfed by that.

[Bobronium]

Indeed, by design, pip-deepfreeze does several pip subprocess calls, so the pip-deepfreeze subprocess invocation time may be dwarfed by that.

Interesting point that I didn't think about. Yeah, it's definitely worth measuring then.

Before doing a PR here, we would first need to expose and document a stable public api in pip-deepfreeze.

I wouldn't say it's required, since we can just set needed sys.args and use pip-deepfreeze's entrypoint.

Not to say that public API would be unwanted, but rather that not having one is not necessarily a blocker.