On 4/26/23 10:53, Daniel P. Berrangé wrote:
> I think it'd be useful for support purposes if the configure
> script summary printed details of how we setup the venv.
> eg perhaps a summary for each python module of whether we
> added it to the venv, or relied on te site packages:
>
> python venv: meson (site), sphinx (venv), avocado (venv)
OK, I'll try to work this out.
At the moment "already had the package" or "installed it from vendored source" is the same pip call, so it's hard to differentiate post-hoc without some further analysis.
One reason this is hard is because I don't have a good method for quickly determining "Do we already have $package that fulfills $depspec" except by invoking pip, and that's costly, 500ms at the absolute fastest I have yet managed. 1.2s in more typical cases. Owowowow.
So, for speed, I combine "do we already have it" and "can we install it from vendored source" into a single call to amortize pip startup cost.
With Python 3.8+ I might be able to inspect the package post-hoc to find where it's installed to and determine if it came from system packages or not.
It's easy to tell the user if we used PyPI or not, though.
I'll experiment.
Yes, I agree John did a great job with the errors but a little more work
is needed to cleanup of mkvenv.py's logging of the "good" case.
In the good case, it worked! you should be happy! :D
(kidding.)
The
installation case is already covered by "pip install"'s output, but we
need to have something like:
mkvenv: Creating {isolated|non-isolated} virtual environment [based on
/home/pbonzini/myvenv]
"based on ..." for nested venv case only?
and when creating the console-scripts shims:
mkvenv: Found avocado v90.0
Sure. Up to the user at that point to figure out if we used that package or not.
e.g. "found meson 0.5.0" might occur even if we require >=1.0.
Simple to implement, though.