# PyTorch-Encoding: 1.2.2 plus today's date, six years past the last tag

> The computer vision toolkit behind three papers, whose README is 106 words of badges and citations pointing at a personal website. Installing it means compiling C++ and CUDA sources after installing torch by hand, and the lint target names three directories the repository does not contain.

**zhanghang1989/PyTorch-Encoding** — A CV toolkit for my papers.

- Repository: https://github.com/zhanghang1989/PyTorch-Encoding
- Website: https://hangzhang.org/PyTorch-Encoding/
- Stars: 2,045 · Forks: 448
- Language: Python
- License: MIT
- Published: 2026-09-11 · Updated: 2026-09-11 · Language: en
- Canonical page: https://hysenlabs.com/projects/zhanghang1989-pytorch-encoding

## The README is badges, links and three BibTeX blocks

The whole file runs to about a hundred words. It opens with four badge links, two of which are the same repository actions badge pointing at the same address, then a byline linking the author's personal site, a documentation heading, three sentences each of which is a link rather than an explanation, and three citation blocks. The documentation link, the image classification model list, and the semantic segmentation model list all point at the author's own website rather than at the repository. The repository does have a documentation directory in its tree, so installation and usage instructions exist somewhere in the project and the front page sends you off-site to find them. The one self-description anywhere is the repository's own summary: a computer vision toolkit for the author's papers.

## Three papers and a copyright header that stopped in 2017

The citations are the substance of the file: split-attention networks from 2020 with leaderboard links for two segmentation benchmarks, a context encoding paper on semantic segmentation from 2018, and a texture encoding network from 2017. The newest of those has leaderboard badges for state-of-the-art entries, which is a claim about results rather than about the code. Against that, the header at the top of the packaging file carries a copyright year of 2017 and a university department and contact address, and it was never updated when the 2020 work landed. So the metadata describes a 2017 project and the citations describe a 2020 one, and the only contact address in the code is an institutional mailbox while the only link in the README is a personal site.

## setup.py imports torch, so torch has to exist first

The packaging file is not a declaration, it is a build script. It imports torch at module level and pulls the CUDA and C++ extension helpers out of torch's own build utilities, then walks two directories inside the package, collecting C++ sources from one and both C++ and CUDA sources from the other, to compile as native extensions. There is no pure-Python path and no wheel to fall back on, so the practical sequence is: install torch and torchvision yourself, then install this. The floors it declares are torch 1.4.0 and torchvision 0.5.0, which is a 2019 baseline, and the dependency list around them reads like a research environment rather than a library's requirements.

## The version is 1.2.2 plus today's date, unless one variable is set

The version logic is the most interesting eight lines in the repository. It starts at 1.2.2, then checks for an environment variable, and if that variable is absent it appends a formatted date to produce something like 1.2.2 followed by a build date. The build then writes the result into a generated version file inside the package, which is created on the fly during installation.

```python
version = '1.2.2'
try:
    if not os.getenv('RELEASE'):
        from datetime import date
        today = date.today()
        day = today.strftime("b%Y%m%d")
        version += day
except Exception:
    pass
```

The newest release tag is 1.2.1, cut in June 2020, so 1.2.2 has never shipped as a tag, and two local builds on different days report different versions. That is a defensible scheme for research code, and it means version comparison against an installed copy tells you when it was built rather than which commit it is.

## The dependency list names one package twice and one that is dead

The requirements list has nine entries and one of them appears twice, verbatim, in two different positions. That is a small thing on its own, but it is a fair signal for how the list is maintained: nothing has reconciled it, and the second copy of the locking library is a dependency on a file-locking helper that a research codebase typically pulls in once while building a dataset. The more consequential entry is a test runner that has been superseded and no longer works on current Python versions, listed as a runtime requirement rather than a development one. With a duplicate, an unmaintained test dependency, and a torch floor from 2019, the list is a snapshot of one machine in 2019 rather than a maintained constraint set.

## The container is from 2020 and forces the CUDA build path

The Dockerfile starts from a GPU-enabled PyTorch container image tagged June 2020, installs a specific pin of the COCO tools, and then runs the packaging script in develop mode against a copied subset of the project. Two details are worth flagging. First, the environment variable that forces the CUDA path is set to 1 before the install, so the container is built for a GPU whether or not one is attached. Second, the two lines that would have pinned torch and torchvision inside the image are commented out, so the container silently inherits whatever versions its base image carries. The image also installs terminal multiplexers and file browsers alongside the build tools, which is a development machine described as a container.

## make lint passes three directories that are not in the tree

The build file has two targets. One runs a linting script from the tests directory and passes four path arguments after it. The other runs a Python linter against the package directory with an extension filter for shared libraries and an additional ignore for a compiled directory. Of the four paths the first target passes, the tree contains one. There is no source directory at the root, no native source directory, and no kernel directory; the top level holds the package, experiments, scripts, tests, documentation, and the packaging files. So the lint target fails on its first argument before it lints anything, and the configuration it depends on, a linter config file in the tests directory, is present and reachable, which makes the missing paths the only thing standing between a contributor and a working check.

## Conclusion

This is code released alongside papers, and it should be read that way. The algorithms are the reason to look, and the reference implementations with their pretrained weights are still linked. What to expect on install is a source build rather than a wheel: the packaging file imports torch at module level and compiles native sources from the package itself, so torch and a compiler have to be in place before anything can begin. Check the version your build reports carefully, because non-release builds carry today's date appended and the newest release tag is from 2020. And if you plan to contribute, ignore the lint target, which passes three directory names the repository does not have.

## FAQ

### How do I install PyTorch-Encoding?

The front page does not contain installation steps; it links to the author's documentation website for detailed instructions. The packaging file imports torch at module level and compiles C++ and CUDA sources from inside the package, so torch and a native toolchain must be in place before the install can start.

### Which PyTorch version does PyTorch-Encoding need?

The declared floors are torch 1.4.0 and torchvision 0.5.0. The container image it ships with dates from June 2020, and the two lines that would have pinned those two libraries inside the image are commented out, so the container inherits whatever its base image carries.

### What version of PyTorch-Encoding is current?

The packaging file declares 1.2.2 and appends a build date to it unless a release environment variable is set, so local builds report something like 1.2.2 with a date appended. The newest release tag is v1.2.1 from 2020-06-29, so 1.2.2 was never tagged.

### Why does make lint fail on a fresh checkout?

Its cpplint step passes four path arguments, and the repository contains only one of them. The pylint step is otherwise runnable, since the configuration file it references exists in the tests directory.

### What papers does PyTorch-Encoding implement code for?

Three: split-attention networks from 2020, context encoding for semantic segmentation from 2018, and a texture encoding network from 2017. Only the first carries leaderboard links for state-of-the-art segmentation results.

## Sources

- [License: MIT](https://github.com/zhanghang1989/PyTorch-Encoding/blob/master/LICENSE)
- [Project website](https://hangzhang.org/PyTorch-Encoding/)
- [README](https://github.com/zhanghang1989/PyTorch-Encoding/blob/master/README.md)
- [Releases](https://github.com/zhanghang1989/PyTorch-Encoding/releases)
- [zhanghang1989/PyTorch-Encoding on GitHub](https://github.com/zhanghang1989/PyTorch-Encoding)

---

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