Skip to content

PCREQ-1.1.0

Latest
Latest

Choose a tag to compare

View all tags
@guanpingxiao guanpingxiao released this 27 Jul 04:57
v1.1.0
eefce93
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

PCREQ v1.1.0 Release Notes

PCREQ 1.1.0 updates the knowledge-base build and version-resolution pipelines. The release improves reproducibility, deterministic output, package metadata handling, and compatibility analysis.

Highlights

  • Direct PyPI-based KB builds. KB construction now downloads wheels or sdists from PyPI and materializes them locally instead of using pip install --target (e891864a).
  • Deterministic processing. Output-affecting unordered iteration was replaced with insertion-ordered structures across extraction, graph construction, Z3 solving, and compatibility checks (268b68d7, 968c0f0c).
  • Improved version solving. User pins are retained when constraints allow; pre-releases, Requires-Python, wildcard constraints, and unsatisfiable dependency constraints are handled more accurately (4e7963ef, 43f2d9c4, 5def8590, 200469ca, 40c5f2cc, 89bf4d66).
  • Better module detection. A shared fallback detects modules from .dist-info, .egg-info, package directories, or single-file modules, including old KB layouts with multiple metadata directories (e3d46e6f, 1e2cd00a, 0aed4a8b).
  • More robust extraction. Namespace packages, metadata-only wheels, nested modules, Python 2 syntax, and public-name aliases are handled more reliably (8cb06670, 061623a2, 22a36474).

Knowledge-Base Pipeline

  • Artifact selection and extraction. Wheel selection uses packaging.tags, including pure-Python wheel tags. Archive extraction checks paths and unsafe members, and wheel/sdist materialization uses separate fallback policies (9bee817d, 67678132, 79670138, 6e46e553, fda74c89).
  • Dependency discovery. Runtime dependencies are discovered incrementally from artifact metadata, with PEP 508 marker evaluation, PyPI fallback, and filtering of optional or build-only dependencies where appropriate (e562b836, a042dd5f, 2d49ec1a, e087c0b6, 91184fee, 9055d4f7).
  • Normalization and compatibility. Package names follow PEP 503 throughout storage and lookup. Local-version suffixes and legacy _/- or release-candidate paths are normalized or resolved through compatibility fallbacks (a2ccf47f, fc796e0a, 46458791, a9661f44, bd2c9ed5).
  • Extraction quality and performance. Nested top_level.txt entries are deduplicated, malformed aliases are normalized, and repeated __init__.py parsing is cached (672fe2ea, 249dd2d3, 687681cc, 11d4f17b).
  • Incremental operation. Completion, failure, and phase markers reduce unnecessary rebuilds. Process locking, structured logging, progress reporting, and consolidated KB reports improve batch operation (9088c10e, 8a5ea60d, 2899bab1, dba0e611, 73450522, 4b994ad6, 9477d4ed, 09d5c20b, 67ad6ef1, 28b8ac36).

Main Pipeline

  • Deterministic solving. Graph traversal and Z3 objective construction preserve discovery order, keeping resolution stable across hash seeds (968c0f0c).
  • User-pin retention and version resolution. Versions pinned in requirements.txt are retained when dependency constraints allow, including pins absent from the KB candidate list; they are adjusted only when constraints require it. Pre-releases, wildcard specifiers, Requires-Python, unsatisfiable constraints, and downgrade-aware dependency cleanup are also handled more accurately (4e7963ef, 43f2d9c4, 5def8590, 200469ca, 40c5f2cc, 89bf4d66, 2eace175).
  • Environment markers and extras. Platform markers are evaluated against the current runtime. Optional dependencies remain visible to call-graph analysis while being excluded from install constraints when appropriate (e2c3566f, 5df71230, a26377d0).
  • Compatibility checking. Multi-module packages use full module paths, and parallel execution uses safer atomic writes (0c6ca575, 707fe56a, d977c666).

Upgrade Notes

  • v1.1.0 can read a v1.0.1 KB, but rebuilding from scratch is recommended for consistent results.
  • Incremental updates of an existing KB remain supported; affected API data is re-extracted when inconsistencies are detected.
  • KB construction is supported on Linux. Cross-platform KB builds are not supported.
  • The configuration schema is unchanged; v1.0.1 configuration files continue to work.
  • Use knowledge_acquisition.py for a single configuration or batch_knowledge.py for a configuration directory.

Full Changelog: v1.0.1...v1.1.0

Assets 2
Loading