PyABSA packs four ABSA subtasks into one API, then contradicts its own Python requirement

Four ABSA subtasks behind a single import surface

PyABSA is not one sentiment function but a namespace of task classes, each mapped in the task table to its own Python entry point and its own hosted Space. Aspect Polarity Classification sits at `pyabsa.AspectPolarityClassification`, Aspect Term Extraction and Polarity Classification at `pyabsa.AspectTermExtraction`, Aspect Sentiment Triplet Extraction at `pyabsa.AspectSentimentTripletExtraction`, and the ASQP/ACOS quadruple task at `pyabsa.AspectCategoryOpinionSentimentTripletExtraction`. A last row folds text classification and adversarial defense in as `pyabsa.TextClassification` and `pyabsa.TextAdversarialDefense`. Four of those names are long enough to type badly, which is why the guide's opening line aliases one of them:

from pyabsa import AspectTermExtraction as ATEPC

Past the alias, a task, a checkpoint family and a device all arrive through one constructor: `ATEPC.AspectExtractor` receives 'multilingual' as its first argument. Repository topics advertise `lcf-bert` and `regression` next to the four extraction tasks, and no entry point in that table names either one, so the topic list promises more architectures than the import surface exposes.

The pip path and the shallow clone path are not the same install

Python 3.8 or later is what the guide asks for, and `python --version` is how it asks you to check. The short path is one line:

pip install -U pyabsa

The longer path exists for the latest mainline, and it is three commands:

git clone https://github.com/yangheng95/PyABSA --depth=1
cd PyABSA
python setup.py install

Either route leaves you with PyTorch and Transformers installed as dependencies, and augmentation plus visualization pushed behind separate optional groups that the installation guide is expected to resolve for you. Two details of the clone are easy to miss. The default branch is v2 and the runnable material lives in `examples-v2/`, so a working copy of a different branch teaches you a different API. And the first prediction needs the network regardless of how the package arrived, because the checkpoint is fetched at inference time, not at import time. `checkpoints.json` at the root is the only file in the tree that could describe that index, and no instruction points you at it.

available_checkpoints resolves weights before any sentence gets scored

Every task class pulls weights through the model zoo first. `available_checkpoints()` returns what sits in the local cache plus what can be fetched remotely, and the ATEPC constructor adds `cal_perplexity=True` alongside `auto_device=True`, where setting the device flag to False forces CPU. The constructor is where resolution happens:

from pyabsa import AspectTermExtraction as ATEPC, available_checkpoints

# View available checkpoints (local + remote)
print(available_checkpoints())

aspect_extractor = ATEPC.AspectExtractor(
    'multilingual',
    auto_device=True,  # False -> force CPU
    cal_perplexity=True
)

Read that block for what it leaves open. The perplexity flag is never defined anywhere in the visible text, so the reason a multilingual extractor needs a perplexity step at all is unstated. The APC example goes further and prints `available_checkpoints(show_ckpts=True)`, a second argument whose output format nobody explains. Neither example names a checkpoint by identifier, and no offline switch appears, so there is no documented way to pin the exact weights your pipeline validated. The per-instance call carries `ignore_error=True`, undefined in the same way, beside two flags that describe themselves:

aspect_extractor.predict(
    ['I love this movie, it is so great!'],
    save_result=True,
    print_result=True,
    ignore_error=True
)

The name says a failing row passes quietly instead of raising. That is what you want in a long job and what you do not want while debugging one bad sentence.

batch_predict takes a dataset name, not a file path

The ATEPC class exposes two different data paths. `aspect_extractor.predict` accepts a plain Python list of strings, which is how one review or one tweet enters the model. `batch_predict` accepts a `target_file` argument whose quickstart value is not a path but an identifier resolved inside the package, `ATEPC.ATEPCDatasetList.Restaurant16`:

inference_source = ATEPC.ATEPCDatasetList.Restaurant16
result = aspect_extractor.batch_predict(
    target_file=inference_source,
    save_result=True,
    print_result=True,
    pred_sentiment=True
)
print(result)

`pred_sentiment=True` asks for polarity alongside the extracted terms instead of terms alone. Because the identifier comes from the package rather than your filesystem, a first batch run depends on a second fetch after the checkpoint download, and a custom corpus has to match whatever parser that identifier expects. Both `save_result=True` and `print_result=True` are set, yet no output file, directory or format is named in the guide, so where a batch run lands is something you have to read off the returned object.

The install window in setup.py contradicts the install guide

Two Python requirements live in this repository and they do not agree. The getting-started section asks for Python 3.8 or later and tells you to confirm with `python --version`. The installation section repeats Python >= 3.8 as its requirement. The packaging metadata says something narrower and directional:

python_requires="<3.11, >=3.10",

That line is not a soft warning. A 3.8 machine passes both README checks and is refused by pip, and so is every interpreter newer than 3.10. If your team standardised on a current interpreter, this framework is not installable until you build a separate 3.10 environment, and the quickstart never mentions that constraint. Version metadata has the same single-source shape, since the packaging script imports both fields from the package rather than writing a literal:

from pyabsa import __name__, __version__

One case-sensitivity trap sits a few lines further down. The repository root lists the readme as `README.MD`, while the packaging script opens `README.md` to load the long description at build time. Those two spellings match on a filesystem that ignores case and do not match on one that does not, so a shallow clone on a case-sensitive filesystem can fail inside the installer before a single dependency is resolved.

requirements.txt bundles docs, tests and a git dependency

The flat list at the repository root shows what a working environment actually contains, and it mixes four kinds of entry. Utility packages sit beside the modelling stack: `findfile`, `autocuda`, `metric-visualizer`, `boostaug`, `update-checker`, `pytorch_warmup` and `seqeval` next to `transformers`, `sentencepiece`, `tokenizers`, `datasets`, `gensim`, `pandas`, `scikit-learn` and `numpy`. One entry is a git URL pointing at the TextAttack repository. One entry is the project itself with an extras marker, `pyabsa[dev]`. `gitpython` carries a comment saying git has to be installed in your operating system, which matters because that URL cannot be fetched by pip on a machine without it.

`pyabsa[dev]` is the line worth reading twice, because the packaging script builds that group from three others, and one of them looks like this:

extras["test"] = [
    "docformatter",
    "isort",
    "flake8",
    "pytest",
    "pytest-xdist",
]

Ask for the development extra and you install docs, test and deploy groups at once, which means sphinx, flake8, pytest, twine and gradio share an environment with torch. Two more groups, tensorflow and sentence_transformers, appear in that file but commented out, so no TensorFlow backend is wired into extras. Pinning is thin as well. `torch>1.0.0` is the only version constraint in the entire list and it is a strict lower bound, so two people building from a clone can end up on different transformers builds with nothing recording which pair was tested.

Four subtasks have hosted demos and the rest have none

Every row of the task table carries two routes: a Python entry point and a Hugging Face Space. Multilingual aspect polarity classification has its own Space, and aspect term extraction, triplet extraction and quadruple extraction all point into the same Gradio Blocks Space. Those links are the real alternative to a local install for a one-off look, because the weights, the queue and the input text all sit on someone else's machine. What the table gives you is a link and nothing else, no parameters and no device choice, so anything you need to configure has to be expressed through the local API instead.

The fifth row breaks the pattern. Text classification and adversarial defense appear under Others with a dash in the demo column, so those two tasks have an import path and no hosted counterpart. Datasets are handled outside the package as well, since the guide points to a separate ABSADatasets repository as the dataset hub and the package reaches into it by name rather than by path. A reviewer comparing this framework with a plain sequence-classification script should notice that the value here is breadth across four extraction shapes, not the quality of any single one, and the table itself offers no numbers to settle that argument.

Two quickstart flags and the training path stay undefined

The feature list claims one API for training, evaluation and inference across ABSA tasks, yet the quickstart sections shown cover inference only, and no training command appears in the text a new user is pointed at. Annotation helpers and metric visualization are announced as features and appear in the dependency list through `boostaug` and `metric-visualizer`, with the tutorials behind them left as links. Maintenance has been uneven in a specific way: the last push landed on 2026-09-20 on the default branch v2, while the newest tagged release, v2.1.12, carries the date 2023-03-21, so commits continue while the packaged version has not moved in over three years. The MIT licence lets you modify and redistribute the code, including inside a closed product, as long as the copyright notice travels with it. Between the version ceiling, the undefined flags and the gap between inference examples and training, the parts of this framework you can evaluate from the front door are the import surface and the checkpoint resolution.

Editorial conclusion

Adopt PyABSA when you need all four ABSA subtasks behind one importable namespace and can hold an environment at Python 3.10, which is the only window setup.py allows. Pass on it for plain sentiment scoring, for text classification and adversarial defense where the task table ends at the import, and for teams on 3.11 or newer. Before installing, run `python --version`, then read what `cal_perplexity` and `ignore_error` do, because the quickstart passes both without defining either. After `pip install -U pyabsa` succeeds in that 3.10 environment, call `available_checkpoints()` once and see what lands in the local cache before you design a pipeline around any of it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yangheng95/PyABSA on GitHub