PCREQ-1.1.0

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

PCREQ-1.0.1

What's Changed

v1.0.1 fixes bugs introduced in v1.0.0 when removing hardcoded local paths from the repository for public release.

The most critical fix is a missing {} in an f-string (f"library_path_prefix..." → f"{library_path_prefix}...") that caused all METADATA and setup.py constraint lookups to silently fail. The variable was treated as a string literal, so every lookup fell through to PyPI JSON. The same change guards download_from_data against write errors on read-only KB directories.

Additional reliability improvements:

• Thread-safe extraction cache with atomic writes (tmp + os.replace) under extraction/cache/, eliminating data races in parallel batch execution.

• _safe_load_json across all 10 call_graph read sites to handle empty or corrupted JSON files from interrupted writes.

• Constraint keys normalized (lowercase, extras stripped) to match library_version.json key format.

• remove_redundant_dependencies now checks other resolved packages' deps before removing a candidate, preventing loss of legitimate transitive dependencies.

• Non-KB versions (e.g., post-releases in requirements.txt but absent from the KB) are prepended to candidate lists rather than appended or inserted at sort position, so the Z3 maximize strategy never prefers them over KB-validated versions.

• Versions normalized via packaging.version.parse throughout to prevent duplicate Z3 variables from inconsistent version representations.

• sorted() in save_dict_to_file for deterministic requirements.txt output.

• knowledgePath normalized with rstrip("/"), original target_version used for report directory naming, end_available_versions guarded against orphaned FDG keys.

Full Changelog: v1.0.0...v1.0.1

PCREQ-1.0.0

PCREQ 1.0.0 Release