proteomics-core

proteomics-core is the compatibility alias for the canonical core owner bijux-proteomics-core. It is the install and import alias for bijux-proteomics-core.

Use this package when you want a shorter distribution and import name while keeping the same scientific processing owner and behavior.

Alias at a glance

• Use proteomics-core when you need a family-specific short name without changing who owns the scientific surface.
• Start with the canonical core package docs because every export in this package forwards into that owner surface.
• Route behavior changes to bijux-proteomics-core; keep this package focused on compatibility naming and import forwarding.

0.3.8 Release Highlights

• The alias now points explicitly at the current core handbook and stops sounding like an independent scientific package.
• Release guidance, boundaries, and verification text now make the forwarding contract easier to audit before publication.

Installation

pip install proteomics-core

Public APIs

The alias forwards core scientific imports through proteomics_core:

from proteomics_core import parse_fasta_document

report = parse_fasta_document(">sp|P11111|PTM1 Protein 1\nMPEPTIDEK\n")

assert report.total_records == 1
assert len(report.accepted_records) == 1
assert report.accepted_records[0].canonical_accession == "P11111"

Package identity

• Distribution name: proteomics-core
• Import root: proteomics_core
• Canonical owner package: bijux-proteomics-core
• Canonical owner import root: bijux_proteomics

Package boundaries

• this package owns compatibility naming for the core package surface
• all scientific semantics remain owned by bijux-proteomics-core
• new exports must appear in the canonical owner before they appear here

What this package must not do

• invent independent core behavior or documentation claims
• fork canonical scientific or workflow semantics
• become a second release-policy owner for the core surface

Contract checkpoints

• forwarded imports must keep canonical behavior without semantic drift
• docs must keep the canonical owner explicit
• alias compatibility tests must stay green when exports or packaging change

Choose this package when

• you need a shorter core-specific distribution name than the canonical owner
• migration constraints prefer proteomics_core imports
• packaging or compatibility work needs a named alias for the core owner

Route elsewhere when

• the change alters scientific parsing, review, or workflow behavior
• the work introduces exports that are not already owned by core
• the package would stop being a forwarding alias

Verification route

• run alias compatibility tests before changing imports or packaging metadata
• review docs/ARCHITECTURE.md, docs/BOUNDARIES.md, and docs/CONTRACTS.md when alias claims or boundaries shift
• validate the canonical core README and tests when behavior changes are being proposed

Review questions

• does the change preserve this package as a compatibility alias only
• is the canonical owner still named clearly for maintainers and consumers
• would the same behavior remain correct if consumers imported core directly

Escalation route

• route scientific behavior changes to bijux-proteomics-core
• stop and review boundaries when the alias starts gaining package-local logic
• escalate before release when package metadata or import routing could confuse core ownership

Consumer impact signals

• import-path or package-name changes are high-impact because downstream code may import this alias directly
• alias contract wording changes should still be reviewed against canonical core
• documentation-only clarifications carry lower release risk than routing or metadata changes

Explicit non-goals

• this package does not own assay-processing or workflow semantics
• this package does not define runtime, intelligence, knowledge, or lab policy
• this package does not replace the canonical core release surface

Documentation

• Release guidance lives in this README.md, this package CHANGELOG.md, and package docs/*.md under the canonical core owner surface.
• Product architecture
• Cross-package ownership
• Canonical core package docs
• Changelog