# Inside the Lightning repository: six install paths, two core packages, one Python import

> PyTorch Lightning automates backpropagation, mixed precision, multi-GPU and distributed training while leaving model logic alone. Its own install section is more interesting than that, because it offers six routes and three package names for the same project.

**Lightning-AI/pytorch-lightning** — Pretrain, finetune ANY AI model of ANY size on 1 or 10,000+ GPUs with zero code changes.

- Repository: https://github.com/Lightning-AI/pytorch-lightning
- Website: https://lightning.ai/pytorch-lightning/?utm_source=ptl_readme&utm_medium=referral&utm_campaign=ptl_readme
- Stars: 31,362 · Forks: 3,801
- Language: Python
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/lightning-ai-pytorch-lightning

## Lightning takes the training loop and leaves you the model

Plain PyTorch means writing the same infrastructure for every project. The README puts the list on one line: backpropagation, mixed precision, multi-GPU, and distributed training. Each is error-prone, each gets reimplemented, and each is a source of bugs that have nothing to do with your model.

Lightning's claim is that it organizes PyTorch code to automate that layer while leaving model logic under your control. The scaling line is the part worth repeating: CPU to multi-node GPUs without changing your core code. The project's own analogy puts PyTorch in the role of Javascript and PyTorch Lightning in the role of ReactJS or NextJS, which describes the arrangement rather than the speed.

Everything above the model class stays yours. The README puts it as a division of labour: you write the science, Lightning handles the engineering.

## A LightningModule describes a whole system

The unit you write is a LightningModule, an nn.Module subclass. The comment above the quick start example is specific about its scope. It defines a full system, and it names an LLM, a diffusion model, an autoencoder, and a simple image classifier as things that fit inside one.

The quick start is a three-stage encoder over 28 by 28 inputs, squeezed to 128 units and then to 3:

```python
class LitAutoEncoder(L.LightningModule):
    def __init__(self):
        super().__init__()
        self.encoder = nn.Sequential(nn.Linear(28 * 28, 128), nn.ReLU(), nn.Linear(128, 3))
```

The file is main.py. Its import line pulls in torch, torch.nn as nn, torch.utils.data as data, torchvision as tv and torch.nn.functional as F, then lightning as L. Running it takes two commands, torchvision first and then the script itself:

```bash
pip install torchvision
python main.py
```

Two names matter throughout the project: lightning is the meta package, and the import is always lightning as L even though the repository is called pytorch-lightning.

## Six install paths, and what the nightly one costs you

The quick start is one line:

```bash
pip install lightning
```

Everything after it is a variant with a different price. Optional dependencies come from an extras marker:

```bash
pip install lightning['extra']
```

Conda users have their own route:

```bash
conda install lightning -c conda-forge
```

Then the README gets candid about source installs. A zip of the release/stable branch is labelled a future release:

```bash
pip install https://github.com/Lightning-AI/lightning/archive/refs/heads/release/stable.zip -U
```

The master zip is labelled bleeding-edge and carries the note no guarantees:

```bash
pip install https://github.com/Lightning-AI/lightning/archive/refs/heads/master.zip -U
```

A sixth path installs only pytorch-lightning from the testing index, which is where a build shows up before it reaches PyPI:

```bash
pip install -iU https://test.pypi.org/simple/ pytorch-lightning
```

Six commands, and the last three trade a published version for a branch that keeps moving.

## PACKAGE_NAME picks which of the three packages you install

One setup.py builds three distributables, and its docstring calls itself the main and only one setup entry point, covering both standalone and joint installation. PyPI offers pytorch-lightning, lightning-fabric, or lightning for all of them.

From a clone, the choice moves into an environment variable that has to be set before pip runs:

```bash
export PACKAGE_NAME=pytorch ; pip install .
export PACKAGE_NAME=fabric ; pip install .
```

Leave it unset and the install covers all three. For development, the same docstring prefers pip install -e . over pip install ., on the grounds that the editable form creates links rather than copying Python files into your pip filesystem, so edits inside the clone take effect immediately.

The variable governs the build step as well, where PACKAGE_NAME takes lightning, pytorch or fabric next to python setup.py sdist or python setup.py bdist_wheel.

## make setup uninstalls lightning before it installs anything

The Makefile removes what is already there first, because an editable install layered over a pre-installed copy is a known source of confusion. A comment names the case outright: in Lightning Studio the lightning package comes pre-installed, and it has to go.

```bash
uv pip uninstall lightning pytorch-lightning lightning-fabric || true
```

What follows is a uv pip install carrying nine -r flags across the fabric and pytorch base, test, test_gpu, extra, strategies and typing requirement files, then -e ".[all]" and pre-commit, after which pre-commit install is run. requirements.txt itself is two lines, both of them includes: ./requirements/fabric/base.txt and ./requirements/pytorch/base.txt.

Three exported variables shape the test run. SLURM_LOCALID is set to 0 to imitate a single node on a scheduler that would otherwise hand out several. SPHINX_MOCK_REQUIREMENTS is set to 1 so the documentation build does not need the real packages installed. PACKAGE_NAME=pytorch narrows the setup to the Lightning Trainer packages. make test runs clean and then setup, so each test run rebuilds the environment from scratch.

## Ruff reads py39 while black holds the line at 120

pyproject.toml records what counts as acceptable Python here. Black and ruff both get a line length of 120, and ruff's target-version is py39. The lint selection is E, W, F, S, RUF018 and UP, which brings in pycodestyle, pyflakes, flake8-bandit, an assignment-in-assert rule and pyupgrade. Format runs with preview enabled.

The docformatter block wraps summaries at 119 and descriptions at 120, with recursive and blank both on, because some docstrings are raw triple-quoted strings that cannot be rewrapped freely. codespell runs at quiet-level 3 with te and compiletime on the ignore list. The _notebooks directory is excluded from black and from ruff's search.

The clean target sweeps what a training run leaves behind: mlruns directories, lightning_log and lightning_logs, _ckpt_ checkpoints, the mypy and pytest caches, the generated documentation directories, build, dist and egg-info, plus the generated subtrees under src/lightning_fabric and src/pytorch_lightning. Anyone keeping logs or checkpoints in the working tree loses them to make clean.

## Three releases, two install targets, one moving branch

The repository is not archived, and its last push was on 2026-09-21. The releases it records are 2.6.6 on 2026-09-10, 2.6.5 on 2026-05-27 and 2.6.4 on 2026-05-20.

Those dates sit next to the install commands in a way worth noticing. pip install lightning takes whatever PyPI currently serves, while the two source installs point at release/stable and at master, and only the first of those is labelled a future release. A team pinning a version number and a team installing from master end up with different code under the same project name.

The licence is Apache-2.0. Alongside it sit the files a project needs when it wants to be cited and when it wants to be told about faults: CITATION.cff, SECURITY.md, a .github directory and .pre-commit-config.yaml. One instruction stands out, a comment in the README forbidding new conda download lines unless a named maintainer approves them.

## LitServe takes serving, Fabric takes control

The README argues against plain PyTorch and leaves the other comparisons to separate projects. Plain PyTorch is the baseline case: the same four pieces of infrastructure, written again for every model. That is the whole difference in approach.

Past training, the answer is another package. The first line under the title sends serving elsewhere, to LitServe, for building custom inference servers in pure Python. Lightning covers pretraining and finetuning, and model serving is pointed at a different repository rather than handled here, which is worth knowing before assuming the scope covers deployment.

The second of the two core packages is Lightning Fabric, the expert-control end of the range. Together with PyTorch Lightning it is what the README calls granular control over how much abstraction you want to add over PyTorch, and it is where the README says PyTorch experts can opt in when they want that level. Lightning Cloud is the third option for people who would rather not own the machines: start training with one command and get GPUs, autoscaling, monitoring and a free tier, or run the same code on your own hardware.

## Conclusion

Take Lightning if your team rewrites the same backpropagation, mixed precision and distributed training scaffolding for every model. Stay on plain PyTorch, or drop to Fabric, when you need the training step under your own control. Verify one thing first: whether pip install lightning brings the optional dependencies you need, since that marker is a separate install.

## FAQ

### What is PyTorch Lightning used for?

It automates the repetitive engineering around a PyTorch model: backpropagation, mixed precision, multi-GPU and distributed training. Your model logic stays yours, and the same core code runs from CPU to multi-node GPUs.

### How do I install PyTorch Lightning?

The quick start is pip install lightning. Variants cover optional dependencies with pip install lightning['extra'], conda with conda install lightning -c conda-forge, a release/stable zip, a master zip, and the testing index with pip install -iU https://test.pypi.org/simple/ pytorch-lightning.

### What is a PyTorch Lightning module?

A LightningModule is an nn.Module subclass that defines a full system rather than a single layer. The README names an LLM, a diffusion model, an autoencoder and a simple image classifier as things that fit inside one.

### What is PyTorch Lightning Fabric?

Fabric is the second of the project's two core packages, the expert-control end of the range. Where PyTorch Lightning automates the training loop, Fabric gives PyTorch experts more direct control over how much abstraction sits over PyTorch.

### What is PyTorch Lightning vs PyTorch?

PyTorch is the tensor library you would otherwise hand-write backpropagation, mixed precision, multi-GPU and distributed training for on every project. PyTorch Lightning is organized PyTorch that automates those four, which the README compares to putting ReactJS or NextJS on top of Javascript.

## Sources

- [Official documentation](https://lightning.ai/pytorch-lightning/?utm_source=ptl_readme&utm_medium=referral&utm_campaign=ptl_readme)
- [Official README](https://github.com/Lightning-AI/pytorch-lightning#readme)
- [Project repository](https://github.com/Lightning-AI/pytorch-lightning)
- [Release notes](https://github.com/Lightning-AI/pytorch-lightning/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lightning-ai-pytorch-lightning