Closed abitrolly closed 3 years ago
The failure happens in VersionSolver.solve()
even before the dependency tree is built.
Hi @abitrolly,
At point of buid error, there is still an ensemble of potentially viable trees. Only when the final set of version pins has been resolved, the 'right' tree can be visualised. It could for instance be that the build error happens for an older version of a package, which would be later discarded during backtracking as it turned out a more recent version (or no version at all) of that package will satisfy by choosing a different version of another package: a different tree in the ensemble.
That said, for the use case you describe, it is possible to log which decision led to building the failing wheel:
https://github.com/ddelange/pipgrip/blob/cca9892be264ecc6504455f3c6bf450449e30c70/src/pipgrip/cli.py#L422
When this line errors, in a re-raising try-except, the last decision in the PartialSolution
before the error occurred can be logged:
last_decision = next(reversed(solver.solution.decisions.items()))
Would that help?
I'm pretty sure this decision coincides with the last INFO: selecting ...
statement in the output: if I understand correctly, that's the one you need.
I need to try that. Having a partial tree with a mark of failing package in the final error message would definitely help.
A bit of context.
Hi @abitrolly, could you give #67 a spin? If that does the trick for you, I'd merge and release :)
Hi @ddelange. #67 already good enough to be merged. Although a perfectionist inside says the error state could be more descriptive. Like having the obvious marker to indicate which package failed and why.
├── pymysql (?)
├x─ pyodbc (ERROR: Failed building wheel)
├── pytest>=2.7.1 (?)
It also interesting to know which packages succeeded to be processes before the failure and which are not.
^ see new visualisation @ https://github.com/ddelange/pipgrip/pull/67#issuecomment-942612902
It also interesting to know which packages succeeded to be processes before the failure and which are not.
all succeeded ones (and there can only be one failed one) for the current best guess tree will be visualised -- for any other tree in the ensemble, I guess there is no trivial way of getting statistics on the solving process apart from analysing the logs...
Thanks for fixing this so fast. ) Do you user some helper tools to wrap releases?
Release builds are triggered from the repo's releases tab (creating and releasing a new tag from there) - github actions (and setuptools_scm) takes care of the rest :) the setup in this repo is slightly outdated, I simplified it in this repo: https://github.com/ddelange/mapply/blob/0.1.9/.github/workflows/CD.yml
Nice. Google uses https://github.com/googleapis/release-please tool, but it uses too boring prefixes for releases. :D
Cool one, didn't know it! For now I avoided release PRs altogether (updating CHANGELOG.md
and bumping __version__
) by letting Github GUI autofill release title and description after I click 'release', and by using setuptools_scm
to detect the new version from git in CD.yml during python setup.py
. However, auto release PR + github release could be interesting for integrating https://github.com/frinyvonnick/gitmoji-changelog 🤔
Need
pipgrip
to render partial tree when installation fails with errors.Use case / motivation
I need to see who pulls in broken dependency when CI jobs fail.
Related Issues
The discussion started here https://github.com/ddelange/pipgrip/issues/52#issuecomment-794050929
And the solution I used was to pipe
requirements.txt
line by line untilpipgrip
fails.However, for this failure the dependencies are specified as
.[test_all]
intox.ini
and configured dynamically insetup.py
.The
cat
also won't work well for deeper levels in hierarchy.