explosion/spaCy

πŸ’« Industrial-strength Natural Language Processing (NLP) in Python

33,755
Stars
about 12 years
Age
0
Published reviews
0
Questions

Reliability breakdown

What drives the reliability score

Component scores measured daily from GitHub activity (2026-07-15).

Continuity30% of headline30

Activity on 9 of 90 tracked days in the last 90 and 0 of 30 in the last 30.

Closure30% of headline34

Merged 0 of 6 PRs opened and closed 0 of 3 issues opened over the last 90 tracked days β€” PR flow carries 55% of this component, issue flow 45%.

Shipping20% of headline12

3 releases in the last 180 days, 0 in the last 90 and 0 in the last 30 β€” a steady cadence scores highest.

Liveness10% of headline81

Last push 62 days ago β€” freshness decays as pushes age (roughly halves every 83 days without a push).

Support burden10% of headline90

Open-issue load isn't tracked for this repo yet.

Adoption confidence59

Modeled β€” how confidently teams are adopting this repo. Stargazers

Maintenance quality40

Modeled from PR/issue responsiveness and upkeep signals. Activity pulse

Risk score41

Modeled β€” lower is better; adoption and continuity risk. Repository

Stays active (30d)20%

Modeled chance the repo stays active over 30 days. Activity pulse

Stays active (90d)43%

Modeled chance the repo stays active over 90 days. Activity pulse

Release rhythm (180d)12

Regularity of releases over the last 180 days. Releases

Maintainer bus risk (90d)65%

Modeled β€” lower is better; concentration of commits in few maintainers. Contributors graph

Topics

Explore related topics

Jump into the topic listings this repository belongs to.

Project Overview

spaCy is an open-source Python library for industrial-strength Natural Language Processing, built and maintained by Explosion. It handles the full structural NLP pipeline β€” tokenization, part-of-speech tagging, dependency parsing, named entity recognition, and text classification β€” in a single composable pass over your documents.

If you need to extract structured information from text at production scale, spaCy is where most teams start. It ships pretrained statistical and transformer-based models for 25+ languages, a clean pipeline API for building custom components, and a Config-driven training system that makes reproducible fine-tuning the default rather than an afterthought.

spaCy uses the MIT license, which has no restrictions for commercial use.

Key Challenges Addressed

Tokenization edge cases: Whitespace splitting mishandles contractions, URLs, abbreviations, and hyphenated compounds. spaCy ships language-specific tokenizers with prefix/suffix rules and special-case mappings that cover real-world text correctly from the start.

Avoiding redundant computation: Most NLP stacks run tokenization, tagging, and entity recognition as separate passes over raw text. spaCy runs all pipeline components against a shared Doc object in one pass β€” downstream components read annotations left by upstream ones rather than re-parsing the input.

Pretrained models without training overhead: Training your own NER model on a large annotated corpus takes weeks. spaCy's pretrained models β€” both CNN-based and transformer-based β€” give you usable accuracy on standard entity types immediately, with documented fine-tuning paths for domain-specific labels.

GPU-accelerated batch inference: Processing documents one at a time in a Python loop is slow. spaCy's Cython-accelerated data structures and nlp.pipe() batch API push real inference throughput without forcing you to rewrite core logic.

Getting Started

Install spaCy and a pretrained English model:

pip install spacy
python -m spacy download en_core_web_sm

Process text and extract entities:

import spacy

nlp = spacy.load("en_core_web_sm")
doc = nlp("Apple is looking at buying U.K. startup for $1 billion")

for ent in doc.ents:
    print(ent.text, ent.label_)

Sharp edges to know immediately:

  • en_core_web_sm accuracy is noticeably lower than transformer models: If you prototype with sm and switch to en_core_web_trf in production, CPU throughput drops 10–20x. Profile your infrastructure for the model tier you will actually ship.

  • Calling nlp(text) in a loop is a silent performance trap: Processing 10,000 texts one by one is roughly 5x slower than nlp.pipe(texts, batch_size=64). This will not error β€” it will just be quietly too slow for production.

  • Custom component ordering is not inferred: If you add a component that reads doc.ents and register it before the ner component runs, you get empty spans every time. Use nlp.add_pipe("my_component", after="ner") explicitly.

  • Dependency version conflicts are common with transformer models: The spacy-transformers package requires specific versions of PyTorch and transformers. Pin all three in your requirements.txt before assuming compatibility.

Features and Use Cases

Named Entity Recognition: spaCy's built-in NER covers standard entity types (PERSON, ORG, GPE, DATE, MONEY, and more) with competitive out-of-the-box accuracy. The spacy train CLI lets you fine-tune the recognizer on domain-specific labels β€” useful for medical, legal, or financial text where standard models miss specialized terminology.

Dependency Parsing: The dependency parser annotates each token with its syntactic head and relation type (subject, object, modifier). You can use this to extract structured facts β€” subject-verb-object triples, prepositional phrase attachments β€” without building a grammar from scratch.

Text Classification: The textcat component trains document-level classifiers that plug into the standard pipeline. Provide labeled data in spaCy's DocBin format, configure a training run with config.cfg, and the output is a serializable model component you can version alongside your other pipeline components.

Custom Components and Extensions: Doc.set_extension(), Span.set_extension(), and Token.set_extension() let you attach arbitrary attributes to spaCy's core objects. Combined with @Language.component registration, you can write domain-specific enrichment layers β€” coreference resolution, relation extraction, entity linking β€” that behave identically to built-in pipeline steps.

Multi-language Pipelines: spaCy provides blank language objects for 73 languages and pretrained models for over 25. For cross-lingual work where you need a consistent annotation API across languages, spaCy's unified interface beats maintaining separate library integrations per language.

Ecosystem and Dependencies

spaCy's ML backend is thinc, Explosion's own composable deep learning library. thinc integrates with PyTorch and TensorFlow β€” if you have an existing model in either framework, you can wrap it as a thinc layer and use it inside a spaCy pipeline component.

The spacy-transformers package connects spaCy to Hugging Face Transformers. You configure a BERT, RoBERTa, or DeBERTa model as a pipeline component, and the standard spaCy training and inference APIs apply from there. You get contextualized embeddings without writing custom training loops.

Explosion's Prodigy annotation tool (paid, not open-source) is designed specifically for feeding labeled data back into spaCy training pipelines. It is the fastest path to high-quality domain-specific training sets if annotation throughput is your bottleneck.

sense2vec provides phrase-level, sense-disambiguated word vectors β€” useful when token-level embeddings lose important context through polysemy.

Architectural Overview

spaCy organizes NLP as a Language object containing an ordered list of pipeline components. Each component is a callable that receives a Doc, annotates it in place, and returns it. The Doc is the central data structure β€” a memory-efficient container built on numpy arrays rather than Python dicts, which keeps object overhead low across large batches.

Tokenization happens before any component runs, using a language-specific Tokenizer that applies prefix/suffix rules, special-case mappings, and whitespace splitting in sequence. Tokenization is unconditional and not pluggable at the component level β€” it runs on every nlp() call.

Model weights are stored separately from pipeline configuration. A config.cfg file describes the architecture, component order, and hyperparameters; a model-best/ directory holds trained weights. This split enables versioning the architecture and weights independently, which matters for reproducible experiments and staged rollouts.

spaCy v3 introduced the Config system, built on confection β€” a hierarchical INI-style configuration language with function registry lookups. Every hyperparameter and architectural choice serializes to a config file and is reproducible from it. This is a meaningful improvement over v2's programmatic setup, where training recipes lived in hand-rolled Python scripts that were easy to diverge from documentation.

Pros and Cons

Production-first throughput: The nlp.pipe() batch API and Cython-accelerated Doc structures handle real document volumes. You do not have to rewrite core paths for scale β€” the architecture expects it.

Single-pass shared Doc: All pipeline components share one object. Downstream components read annotations left by upstream ones without re-parsing raw text, saving both memory and compute.

Config-driven reproducible training: spacy train with a config.cfg file is the default workflow. You get reproducible training runs as the baseline rather than something to retrofit.

Active maintenance: Explosion ships regular releases with detailed changelogs. The project has been continuously active since 2016.

Config learning curve: Debugging broken config.cfg files with nested registry lookups is genuinely difficult. Error messages sometimes point to the wrong section. Budget time for this before your first training run.

Transformer dependency conflicts: spacy-transformers plus compatible PyTorch plus transformers requires careful version pinning. Misconfigured installs fail at runtime in ways that do not always surface a clean error message.

No iterative prediction refinement: The built-in NER and parser assume a single-pass model. If your task needs multiple prediction heads with shared gradients or iterative refinement, you need thinc-level customization, which adds significant complexity.

Custom training data format: Fine-tuning requires learning spaCy's DocBin format and spacy train CLI workflow. There is no shortcut equivalent to Hugging Face's Trainer.train() for users coming from that ecosystem.

Comparison and Alternatives

Measured 90-day trends for this project and its alternatives.

GitHub stars

Weekly star gains

36180
Full metrics details

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

SpaCy

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
NLTK

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

179 observed daily rows. Missing days are not fabricated.

DateValue
Transformers

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

59 observed daily rows. Missing days are not fabricated.

DateValue
Stanza

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue

Issues opened

Weekly total

43220
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

SpaCy

GitHub API observation. Historical values render only when the source provides a real observation for that day.

131 observed daily rows. Missing days are not fabricated.

DateValue
NLTK

GitHub API observation. Historical values render only when the source provides a real observation for that day.

143 observed daily rows. Missing days are not fabricated.

DateValue
Transformers

GitHub API observation. Historical values render only when the source provides a real observation for that day.

36 observed daily rows. Missing days are not fabricated.

DateValue
Stanza

GitHub API observation. Historical values render only when the source provides a real observation for that day.

143 observed daily rows. Missing days are not fabricated.

DateValue

Issues closed

Weekly total

35180
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

SpaCy

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

131 observed daily rows. Missing days are not fabricated.

DateValue
NLTK

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

143 observed daily rows. Missing days are not fabricated.

DateValue
Transformers

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

36 observed daily rows. Missing days are not fabricated.

DateValue
Stanza

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

143 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests opened

Weekly total

167840
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

SpaCy

GitHub API observation. Historical values render only when the source provides a real observation for that day.

131 observed daily rows. Missing days are not fabricated.

DateValue
NLTK

GitHub API observation. Historical values render only when the source provides a real observation for that day.

143 observed daily rows. Missing days are not fabricated.

DateValue
Transformers

GitHub API observation. Historical values render only when the source provides a real observation for that day.

36 observed daily rows. Missing days are not fabricated.

DateValue
Stanza

GitHub API observation. Historical values render only when the source provides a real observation for that day.

143 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests closed

Weekly total

137690
Full metrics details

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

SpaCy

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

131 observed daily rows. Missing days are not fabricated.

DateValue
NLTK

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

143 observed daily rows. Missing days are not fabricated.

DateValue
Transformers

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

36 observed daily rows. Missing days are not fabricated.

DateValue
Stanza

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

143 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests merged

Weekly total

91460
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

SpaCy

GitHub API observation. Historical values render only when the source provides a real observation for that day.

131 observed daily rows. Missing days are not fabricated.

DateValue
NLTK

GitHub API observation. Historical values render only when the source provides a real observation for that day.

143 observed daily rows. Missing days are not fabricated.

DateValue
Transformers

GitHub API observation. Historical values render only when the source provides a real observation for that day.

36 observed daily rows. Missing days are not fabricated.

DateValue
Stanza

GitHub API observation. Historical values render only when the source provides a real observation for that day.

143 observed daily rows. Missing days are not fabricated.

DateValue

Open/closed pull request ratio

Weekly average

100500
Full metrics details

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

SpaCy

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
NLTK

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

179 observed daily rows. Missing days are not fabricated.

DateValue
Transformers

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

59 observed daily rows. Missing days are not fabricated.

DateValue
Stanza

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue

Open/closed issues ratio

Weekly average

100500
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

SpaCy

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
NLTK

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

179 observed daily rows. Missing days are not fabricated.

DateValue
Transformers

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

59 observed daily rows. Missing days are not fabricated.

DateValue
Stanza

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue

Releases

Weekly total

110
Full metrics details

GitHub release published_at events bucketed by UTC day; drafts are excluded.

SpaCy

GitHub release published_at events bucketed by UTC day; drafts are excluded.

180 observed daily rows. Missing days are not fabricated.

DateValue
NLTK

GitHub release published_at events bucketed by UTC day; drafts are excluded.

179 observed daily rows. Missing days are not fabricated.

DateValue
Transformers

GitHub release published_at events bucketed by UTC day; drafts are excluded.

59 observed daily rows. Missing days are not fabricated.

DateValue
Stanza

GitHub release published_at events bucketed by UTC day; drafts are excluded.

180 observed daily rows. Missing days are not fabricated.

DateValue

Hotness score

Weekly average

100500
Full metrics details

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

SpaCy

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 Γ— Hot today + 0.40 Γ— Hot week + 0.20 Γ— Breakout.

  • Same-day multiplier = stars 1d Γ· max(1, stars 7d Γ· 7)
  • Weekly multiplier = stars 7d Γ· max(1, stars 30d Γ· 30 Γ— 7)
  • Fortnight multiplier = stars 14d Γ· max(1, stars 90d Γ· 90 Γ— 14)
  • Hot today = clamp(70 Γ— log-scale(stars 1d, 1000) + 30 Γ— breakout-scale(same-day, 4))
  • Hot week = clamp(75 Γ— log-scale(stars 7d, 5000) + 25 Γ— breakout-scale(weekly, 3))
  • Breakout = clamp(35 Γ— breakout-scale(same-day, 4) + 40 Γ— breakout-scale(weekly, 3) + 25 Γ— breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
NLTK

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

179 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 Γ— Hot today + 0.40 Γ— Hot week + 0.20 Γ— Breakout.

  • Same-day multiplier = stars 1d Γ· max(1, stars 7d Γ· 7)
  • Weekly multiplier = stars 7d Γ· max(1, stars 30d Γ· 30 Γ— 7)
  • Fortnight multiplier = stars 14d Γ· max(1, stars 90d Γ· 90 Γ— 14)
  • Hot today = clamp(70 Γ— log-scale(stars 1d, 1000) + 30 Γ— breakout-scale(same-day, 4))
  • Hot week = clamp(75 Γ— log-scale(stars 7d, 5000) + 25 Γ— breakout-scale(weekly, 3))
  • Breakout = clamp(35 Γ— breakout-scale(same-day, 4) + 40 Γ— breakout-scale(weekly, 3) + 25 Γ— breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
Transformers

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

59 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 Γ— Hot today + 0.40 Γ— Hot week + 0.20 Γ— Breakout.

  • Same-day multiplier = stars 1d Γ· max(1, stars 7d Γ· 7)
  • Weekly multiplier = stars 7d Γ· max(1, stars 30d Γ· 30 Γ— 7)
  • Fortnight multiplier = stars 14d Γ· max(1, stars 90d Γ· 90 Γ— 14)
  • Hot today = clamp(70 Γ— log-scale(stars 1d, 1000) + 30 Γ— breakout-scale(same-day, 4))
  • Hot week = clamp(75 Γ— log-scale(stars 7d, 5000) + 25 Γ— breakout-scale(weekly, 3))
  • Breakout = clamp(35 Γ— breakout-scale(same-day, 4) + 40 Γ— breakout-scale(weekly, 3) + 25 Γ— breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
Stanza

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 Γ— Hot today + 0.40 Γ— Hot week + 0.20 Γ— Breakout.

  • Same-day multiplier = stars 1d Γ· max(1, stars 7d Γ· 7)
  • Weekly multiplier = stars 7d Γ· max(1, stars 30d Γ· 30 Γ— 7)
  • Fortnight multiplier = stars 14d Γ· max(1, stars 90d Γ· 90 Γ— 14)
  • Hot today = clamp(70 Γ— log-scale(stars 1d, 1000) + 30 Γ— breakout-scale(same-day, 4))
  • Hot week = clamp(75 Γ— log-scale(stars 7d, 5000) + 25 Γ— breakout-scale(weekly, 3))
  • Breakout = clamp(35 Γ— breakout-scale(same-day, 4) + 40 Γ— breakout-scale(weekly, 3) + 25 Γ— breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score

Reliability score

Weekly average

100500
Full metrics details

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

SpaCy

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 Γ— Continuity + 0.30 Γ— Closure + 0.20 Γ— Shipping + 0.10 Γ— Liveness + 0.10 Γ— Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 Γ— (20% Γ— release ratio 30d + 30% Γ— release ratio 90d + 50% Γ— release ratio 180d); ratios are releases Γ· 2, 6, and 12, capped at 1
  • Support burden = 100 βˆ’ 2 Γ— open issues per 1,000 stars
  • Liveness = 100 Γ— exp(βˆ’pushed days ago Γ· 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
NLTK

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

179 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 Γ— Continuity + 0.30 Γ— Closure + 0.20 Γ— Shipping + 0.10 Γ— Liveness + 0.10 Γ— Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 Γ— (20% Γ— release ratio 30d + 30% Γ— release ratio 90d + 50% Γ— release ratio 180d); ratios are releases Γ· 2, 6, and 12, capped at 1
  • Support burden = 100 βˆ’ 2 Γ— open issues per 1,000 stars
  • Liveness = 100 Γ— exp(βˆ’pushed days ago Γ· 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
Transformers

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

59 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 Γ— Continuity + 0.30 Γ— Closure + 0.20 Γ— Shipping + 0.10 Γ— Liveness + 0.10 Γ— Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 Γ— (20% Γ— release ratio 30d + 30% Γ— release ratio 90d + 50% Γ— release ratio 180d); ratios are releases Γ· 2, 6, and 12, capped at 1
  • Support burden = 100 βˆ’ 2 Γ— open issues per 1,000 stars
  • Liveness = 100 Γ— exp(βˆ’pushed days ago Γ· 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
Stanza

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 Γ— Continuity + 0.30 Γ— Closure + 0.20 Γ— Shipping + 0.10 Γ— Liveness + 0.10 Γ— Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 Γ— (20% Γ— release ratio 30d + 30% Γ— release ratio 90d + 50% Γ— release ratio 180d); ratios are releases Γ· 2, 6, and 12, capped at 1
  • Support burden = 100 βˆ’ 2 Γ— open issues per 1,000 stars
  • Liveness = 100 Γ— exp(βˆ’pushed days ago Γ· 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score

spaCy competes with several well-established Python NLP libraries. The right choice depends on whether you prioritize pipeline structure, model selection flexibility, or specific task coverage.

NLTK is the canonical teaching library. It is thorough for learning NLP concepts but not designed for production β€” no GPU support, slow inference, and an API built around pedagogy rather than throughput. If you are building something that ships to real users, NLTK is not the right tool.

Hugging Face Transformers gives you access to the full breadth of pretrained transformer models with strong community support for new architectures as they are published. If your bottleneck is model quality and you need to compare multiple architectures quickly, Transformers is more flexible than spaCy alone. The spacy-transformers integration means you do not have to choose one and abandon the other.

Stanza (Stanford NLP) provides strong accuracy on low-resource languages and covers more language models than spaCy. If you need cross-lingual NLP across languages outside spaCy's model set, Stanza is worth testing. It is slower and less composable than spaCy for high-throughput pipelines.

Flair specializes in sequence labeling β€” NER, POS, chunking β€” using contextual string embeddings and character-level models. It is a strong choice for domain-specific NER on non-English text when you need fine-grained sequence annotation and do not need the full structural pipeline that spaCy provides.

Gensim focuses on topic modeling and word vector training β€” Word2Vec, FastText, LDA, LSI. It does not do NER or dependency parsing; it is complementary to spaCy rather than a replacement. If you need both structural NLP and topic discovery, use both.

Project Repo Hotness (~6mo) PRs merged (~6mo) Star growth (~6mo)
spaCy https://github.com/explosion/spaCy 78.06 5 1796
NLTK https://github.com/nltk/nltk metrics pending 0 20
Transformers https://github.com/huggingface/transformers 17.39 2842 42308
Stanza https://github.com/stanfordnlp/stanza metrics pending 0 20
Flair https://github.com/flairNLP/flair metrics pending 0 metrics pending
Gensim https://github.com/RaRe-Technologies/gensim metrics pending 0 metrics pending

The best overall alternative is Hugging Face Transformers. It has broader model coverage, a larger active research community, and significantly more pretrained model options than any other Python NLP library. For teams whose main bottleneck is model quality rather than pipeline management, Transformers is the more future-proof choice.

Conclusion

spaCy is the right pick for backend engineers and data engineers building production NLP pipelines who need fast, accurate entity extraction and syntactic analysis on real document volumes β€” the spaCy documentation is thorough, and the GitHub repository includes runnable examples that get you to first results within an hour.

Do not call nlp(text) in a loop on large document sets β€” processing thousands of texts this way is silently 5x slower than nlp.pipe(texts, batch_size=64), and the throughput gap only surfaces under production load when it is hardest to fix. Start with python -m spacy download en_core_web_sm and write every pipeline from line one using nlp.pipe().

Join the conversation

Reviews Β· Questions Β· Posts

Share what you know about spaCy β€” write a review from your real experience, ask an implementation question, or publish a post about how you use it.

Share your experience

Write or update your review

Explain what worked, what broke down, and what another team should know before adopting spaCy.

Write your review now β€” it saves locally and publishes automatically after you sign in.

Rating
Positive attributes
Negative attributes

Project Q&A

Questions and answers

Browse implementation threads tied directly to explosion/spaCy. Each question links through to the full answer page.

Q&A No threads yet

Be the first to ask how teams run spaCy in production. Every question you post becomes a durable, searchable answer page other developers can find.

Ask the first question

Related posts

Posts tagged with the same topics

These posts come from the same topic surface as this repo, so readers can move from project evaluation into practical writeups and migration notes without leaving context.

Posts No topic-linked posts yet

Share how your team uses spaCy β€” a migration note, an architecture writeup, or a comparison. Your post reaches everyone browsing these same topics.

Write the first post
Get a weekly email with the hottest new projects in the Deep Learning Frameworks and Artificial Intelligence world.
No Spam. Unsubscribe easily at any time.

Copyright 2018-2026 Awesome Open Source.  All rights reserved.