Roboflow Inference: what the packaging and build files actually say

setup.py calls the distribution inference-development, the quickstart calls it inference-cli

The quickstart is a single line, and it installs something called inference-cli:

pip install inference-cli && inference server start --dev

That command comes from the console script registered in setup.py, which binds `inference=inference_cli.main:app`. What setup.py does not do is declare a distribution of that name. The name it hands to setuptools is `inference-development`, with author Roboflow and author_email [email protected], so the packaging metadata in this checkout describes a development install rather than the package a reader installs. The Python client adds a fourth identifier: the same page asks for `pip install inference-sdk`, and the code imports `inference_sdk`. Four strings in play, and the only one that names a distribution the reader can type is the one the repository does not declare.

workflows/ is in the find_packages exclude list of the file that builds the package

setup.py hands find_packages an exclude list: docker, docs, requirements, tests, development, stream_vision, streamvision, roboflow_workflows and workflows, each with a dotted variant alongside. The two top level directories that carry the product's headline features, workflows/ and stream_vision/, are both named in that list. The Makefile holds the answer. Four of its phony targets are create_workflows_wheel, create_streamvision_wheel, create_models_wheel and create_isolation_wheels, which says those pieces are shipped as separate artifacts rather than folded into the main package. A reader who installs this checkout therefore does not receive the Workflows runtime the README spends most of its length on, and the answer to where that comes from lives in the Makefile, not in setup.py. Exactly one non Python file is declared as package data, the `bpe_simple_vocab_16e6.txt.gz` file for `inference.models.perception_encoder.vision_encoder`.

read_requirements turns every line of the requirements files into a dependency string

The dependency list is assembled by a short helper. `read_requirements` wraps a single path into a list, opens each file in turn, and appends `line.strip()` for every line it reads. There is no filter along the way, so a blank line or a comment becomes an entry in install_requires, and nothing records which file each entry came from. The one visible call site passes several paths at once, starting with `requirements/_requirements.txt`, `requirements/requirements.cpu.txt` and `requirements/requirements.cli.txt`, and the list continues past the point where the file stops. The base requirements and the file whose name ends in .cpu.txt land in the same flat list, and nothing at the call site separates them by marker, so any platform split has to live inside the files themselves. Worth knowing before you debug an install failure: a commented out pin is handed to pip as if it were a requirement.

Development mode serves the notebook tour and the API from the same port

In development mode the server hosts a Jupyter notebook quickstart at http://localhost:9001/notebook/start, and the server itself defaults to localhost:9001. One port, two jobs: the guided tour meant to walk a newcomer through the setup, and the HTTP surface the SDK calls. The client is a separate install:

pip install inference-sdk

from inference_sdk import InferenceHTTPClient

client = InferenceHTTPClient(
    api_url="http://localhost:9001", # use local inference server
    # api_key="<YOUR API KEY>" # optional to access your private data and models
)

That commented api_key line is the only access control mentioned anywhere in the example, and it is described as optional, needed for private data and models. The call after it passes workspace_name, workflow_id, images and parameters, and the version of that call printed here stops right after `parameters={`, so the shape of the parameters dictionary has to come from the Workflows documentation rather than from the example.

The CPU test container pins MAX_BATCH_SIZE=17 and expands three variables nothing assigns

The test targets wrap docker run around a Roboflow test image. The CPU one reads, in full:

docker run -d --rm -p $(PORT):$(PORT) -e USE_INFERENCE_MODELS=$(USE_INFERENCE_MODELS) -e PORT=$(PORT) -e MAX_BATCH_SIZE=17 --name inference-test roboflow/${INFERENCE_SERVER_REPO}:test

Four details deserve a second read. `-e MAX_BATCH_SIZE=17` is the only value hardcoded into the recipe, and 17 is an odd default batch size that the file gives no way to interpret. `$(PORT)`, `$(USE_INFERENCE_MODELS)` and `$(INFERENCE_SERVER_REPO)` expand from variables the Makefile never assigns, so the target only resolves when the caller passes them on the command line; left empty, `-p $(PORT):$(PORT)` collapses to a bare `-p :`, and `roboflow/${INFERENCE_SERVER_REPO}:test` becomes a tag with no repository in front of it. `--name inference-test` is fixed too, so a second run while the first container is still alive fails on the name rather than on the port. The GPU sibling begins identically and stops after `docker run -d --rm`.

serve and serve-full are the only targets left out of .PHONY

The .PHONY line names seven targets: style, check_code_quality, download_fonts and the four wheel builders. The two documentation targets are not on it. `serve` runs `SKIP_CODEGEN=1 python -m zensical serve`, and `serve-full` runs the same command without that variable, so the pair differs by exactly one thing, whether code generation is skipped. Both also step past the `mkdocs.yml` sitting at the top level of the tree, which is the configuration file a reader would expect a docs server to read. PYTHONPATH is exported as `.`, so the served documentation imports the working tree rather than anything installed. The effect is narrow but real: a file named `serve` or `serve-full` appearing in that directory would leave make convinced the target is already up to date, while the seven declared targets always rebuild.

The second flake8 pass is advisory, and three paths are exempt from formatting

check_code_quality runs black and isort in check mode over `check_dirs`, which the file sets to `inference inference_sdk workflows stream_vision`. Then flake8 runs twice. The first invocation selects only E9, F63, F7 and F82, and the comment above it says the point is to stop the build on Python syntax errors and undefined names; that is the pass with teeth. The second sets --max-line-length=88 alongside --exit-zero and --ignore=D --extend-ignore=E203,E501,W503, with a comment saying exit-zero treats all errors as warnings. So lint findings outside that four code list can never fail a build. That split is deliberate rather than broken, but it means a green check_code_quality says nothing about style. Both formatters also skip `__init__.py`, `node_modules` and `perception_encoder/vision_encoder/`, the last being the vendored directory whose vocabulary file is the single declared package data entry.

LICENSE and LICENSE.core both sit at the root, and setup.py names neither

The top level of the tree carries two license files, `LICENSE` and `LICENSE.core`, and the badge at the top of the README links to LICENSE.core. setup.py passes no license argument at all, so the distribution built from this file carries no license metadata. Which of the two files governs a given install is not settled by anything visible here. The naming implies a split between the core library and something beside it, but neither the packaging file, the Makefile nor the visible documentation states where that boundary falls. A team that needs to satisfy a license obligation has to open the file its own install actually ships and read it, instead of trusting the badge. The last push to the default branch landed on 2026-10-03, and the three most recent tags are v1.7.3 from 2026-10-02, v1.7.2 from 2026-09-25 and v1.6.2 from 2026-09-18, so the file itself is current even where the paperwork is thin.

Editorial conclusion

Adopt this if your team already lives inside Roboflow's ecosystem and wants the server, the Workflows builder and the hosted model catalog behind one URL. Before you depend on it, read three files yourself: setup.py for what the wheel leaves out, the requirements files for what read_requirements turns into dependency strings, and the LICENSE versus LICENSE.core question, which setup.py does not answer at all. Anyone building against Workflows from a source checkout needs the Makefile's wheel targets, since installing this checkout on its own does not hand over the workflows package.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. roboflow/inference on GitHub