spacy-legacy

Backwards-compatible legacy architectures and registered functions for spaCy v3.x

Library
PyPI
v3.0.12
4stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
24/100Needs Attention
Development Activity0
Maintenance20
Community16
Maturity60
Momentum0

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
54/100Fair
Architecture62
Code Quality65
Innovation40
Learning Curve50

spacy-legacy is a companion package to spaCy that preserves outdated versions of registered functions — model architectures, pipeline component implementations, loggers, and scorers — after spaCy’s core library moves on to a newer version of the same function. Instead of breaking existing config files that reference an older registered name like spacy.Tok2Vec.v1, spaCy falls back to spacy-legacy’s implementation when the core package no longer ships it, which lets the main spaCy codebase stay lean and current without invalidating models or configs built against earlier releases.

It is installed automatically as a transitive dependency of spaCy and is not something most users interact with directly; its entire surface is a set of functions registered via entry points (defined in setup.cfg) under the spacy-legacy prefix, so spaCy’s config-resolution system can discover and load them transparently when a config asks for a version that has been retired from the core package.

What You Get

  • Legacy versions of spaCy model architectures (Tok2Vec, parser, tagger, textcat, entity linker) preserved for configs that still reference older function versions
  • Legacy pipeline component implementations (e.g. an older entity_linker component) kept resolvable via spaCy’s config system
  • Legacy loggers and scorers registered under the spacy-legacy entry-point prefix
  • Automatic fallback resolution: when spaCy’s config references a function no longer in core spaCy, spaCy checks spacy-legacy before failing

Common Use Cases

  • Loading or training with a spaCy config file authored against an older spaCy version without manually porting every registered function reference
  • Keeping a previously trained spaCy pipeline reproducible after upgrading the core spaCy package to a version that dropped an older architecture
  • Explicitly pinning a config to a known-older function version (e.g. spacy-legacy.Tok2Vec.v1) when a newer default changed model behavior unexpectedly

Under The Hood

Architecture - the package is organized by function category (architectures/, components/, layers/) mirroring spaCy’s own module layout, with each legacy implementation registered under the spacy-legacy namespace via entry points declared in setup.cfg; spaCy’s config-resolution (Thinc’s registry system) checks this entry-point namespace as a fallback whenever a requested function name isn’t found in the core package’s own registry. Tech Stack - pure Python (99.5%), thin wrapper around Thinc/spaCy’s model-building primitives with no independent runtime dependencies beyond what spaCy itself already requires; packaged with classic setup.py/setup.cfg. Code Quality - a dedicated spacy_legacy/tests/ directory with per-category test modules (test_scorers.py, test_layer.py, test_logger.py, test_legacy.py) plus nested pipeline/ and parser/ test suites; the repository has had no commits since January 2024, consistent with its narrow, stable, rarely-changing purpose as a compatibility shim. API Design - there is effectively no direct-use API surface; the entire package is consumed indirectly through spaCy’s config system via registered function names, which keeps it invisible to typical users by design.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search