# Pyramid's hello world runs on wsgiref, and its manifest caps setuptools below version 82

> A look at a WSGI framework classified as Mature: an introductory example that serves from the standard library rather than a bundled server, nine runtime dependencies each carrying a comment naming the one feature it is there for, an upper pin on setuptools so pkg_resources survives, four console scripts of which two exist to show you what you have, and a repository root with nine top-level text files documenting how the project is run.

**Pylons/pyramid** — Pyramid - A Python web framework

- Repository: https://github.com/Pylons/pyramid
- Website: https://trypyramid.com/
- Stars: 4,100 · Forks: 893
- Language: Python
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/pylons-pyramid

## The introductory example serves from wsgiref on port 6543

The whole framework fits in one example, and the example does not use a Pyramid server.

```python
from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.response import Response

def hello_world(request):
    return Response('Hello World!')

if __name__ == '__main__':
    with Configurator() as config:
        config.add_route('hello', '/')
        config.add_view(hello_world, route_name='hello')
        app = config.make_wsgi_app()
    server = make_server('0.0.0.0', 6543, app)
    server.serve_forever()
```

Three things in that block are worth naming. The server comes from the standard library's simple WSGI server module, not from the framework, so the example has no server dependency at all. The application object is produced by a method named make_wsgi_app, which says what the framework is: a WSGI application builder, nothing more. And the port is 6543, which is a memorable non-default number rather than the usual 8000.

The configuration is three calls on a configurator used as a context manager: one to add a route with a name and a path, one to attach a view to that route name, and one to produce the application. The route name is what the view is bound to, not the path, which is the shape of the routing model in miniature.

That is consistent with how the project describes itself: small, fast, down-to-earth, and making deployment more predictable. There is no application object to subclass and no server to configure, because the framework stops at the WSGI callable and lets you choose what runs it.

## Every runtime dependency carries a comment naming the one feature it is there for

The dependency list in the manifest is nine entries long and every one has an inline comment. That is unusual, and the comments turn the list into a specification of what the framework actually uses.

The webob entry is pinned at 1.8.3 or newer with the comment about a specific method on a request header class. The zope.interface entry is pinned at 3.8.0 or newer because of a registry implementation in that package, which is what the configuration system is built on. The venusian entry is pinned for a decorator named ignore. The hupper entry is pinned for ignore_files support.

Two entries are there for Python 3 compatibility rather than for a feature: translationstring and zope.deprecation. Those comments are the kind that get written once and never updated, and they are a useful signal of how long the dependency list has been stable.

Then there are the two configuration entries, plaster and a PasteDeploy integration, which together are why Pyramid can read a configuration from an ini file if you want it to and from Python if you do not.

And then there is the entry that changes how you install anything:

```toml
"setuptools < 82",  # require pkg_resources
```

That is a hard upper bound on setuptools, at runtime, with the reason written next to it. pkg_resources is the packaging API that newer setuptools versions have been removing, and Pyramid's runtime still requires it. So the manifest is not just describing what Pyramid needs; it is preventing an unrelated upgrade elsewhere in your environment from breaking it.

## Four console scripts, two of which exist to show you what you have

Installing the package puts four commands on your path, and the list tells you something about how the project expects you to work.

There is pserve, which is the development server. There is pshell, which is an interactive shell with your application's registry and configuration loaded, so you can inspect and manipulate a running application from a prompt rather than from a debugger.

Then there are proutes and pviews. Those two are introspection commands, and their existence is the interesting part. A framework where the routes and the views are registered by name through a configuration object has two questions that are otherwise awkward to answer: what routes exist, and which view is bound to which. Two dedicated commands mean neither question requires you to add logging or write a throwaway script.

That is a small thing that says something about the project's priorities. A framework with implicit conventions can print its configuration by definition. One built on explicit registration needs to offer you a way to look at what you registered.

It also fits the description of the project as making things more predictable. The same explicitness that makes the hello world three configuration calls makes the state of the application something you can print on demand.

## Classified as Mature, tested on PyPy, and carrying a development version

Three facts from the manifest tell you what kind of project this is.

The first is the development status classifier, which is 6 and Mature. That is the highest value in that classification scheme, and it is worth setting against how the manifest's other entries read. The version is 2.2.dev0, which is a development version rather than a release. The last push was on 2026-08-04, and there are no GitHub releases on the repository.

So the branch carries a development version of a framework classified as mature. Those are not in conflict: the classification describes the API's stability, and the version describes where this checkout sits. It does mean there is no tag on the repository to pin, and the version you get from the branch is not a released artefact.

The second fact is the interpreter support. The floor is Python 3.10 and the classifiers name 3.10 through 3.14, and both CPython and PyPy are listed as supported implementations. PyPy support in a WSGI framework is a reasonable thing to claim and a slightly unusual one to see in a classifier list, because it means the test matrix runs there.

The third is the topic classification, which names both the general internet topic and the WSGI one. The framework is not trying to be anything other than a WSGI component, and the classification says so before you read a line of documentation.

## The licence is a Repoze BSD derivative and the manifest references it by name

The licence situation is specific and slightly old-fashioned, in a way that is worth understanding before you copy anything from it.

The readme says Pyramid is offered under the BSD-derived Repoze Public License, and the manifest records it as a licence reference string rather than a standard SPDX identifier, with the licence file named separately.

A licence reference rather than an identifier is the packaging format's way of saying this is a licence with a custom name that the tooling does not recognise. The effect is that automated licence scanners will not resolve it to a known licence, and a compliance tool asking which licence applies will need a human to answer.

Two more files sit beside it. There is a licence file that the manifest names as the licence file, and there is a separate copyright file in the repository root.

The authorship section of the readme is equally specific. It says Pyramid is made available by a named consulting company and by a team of contributors, with a link to the contributors graph. So the copyright is held through a company rather than by an individual or a foundation, and the project sits inside the Pylons Project rather than standing alone. The readme's own links for documentation point at the Pylons Project's documentation host, which is the clearest sign that this is a project within an umbrella rather than an independent one.

## Nine text files at the root document the process, and one of them is about rewriting history

The repository root is mostly documentation, and the file names are a map of how the project is run.

There are two developer guides, one for hacking and one for contributing, and the readme names what each covers: running tests, adding features, coding style, and updating documentation. There is a separate releasing file, which is how a project with no published tags on the repository still documents its release process. There is a to-do file. There is a contributors file and a copyright file.

Then there are two history files, and the distinction is deliberate: one is the change log and the other is the history. Two files rather than one usually means one is append-only per release and the other accumulates narrative.

The outlier is a file whose name is a tool name. BFG History is a repository rewriting tool, and a file named after it at the root of a project with a mailmap file and a blame-ignore-aware attributes file is a record that history has been rewritten. That is normal and healthy in a long-lived project, and it is also why you should treat commit hashes from years ago with suspicion.

Underneath the documentation, the code is in a src directory rather than at the root, there is a tox file for running the test suite across environments, a coverage configuration, a flake8 configuration, and a read the docs configuration.

## Conclusion

Pyramid fits a team that wants an explicit, configurable web framework with no conventions imposed and a dependency list small enough to read, and that is willing to use PasteDeploy-style configuration files. It does not fit someone who wants batteries included, since there is no bundled server, no ORM and no admin interface in the package. Before you adopt it, read the dependency comments in the manifest rather than the feature documentation, because they tell you which single feature each library is there for and one of them caps setuptools, which affects any environment you install it into, and check the version you would get, because the branch carries a development version rather than a release.

## FAQ

### What is Pyramid the Python framework?

A small, fast, down-to-earth open source Python web framework that produces a WSGI application and is a project of the Pylons Project. It is described as making real-world web application development and deployment more fun, more predictable and more productive, and its manifest classifies it as Development Status 6, Mature.

### Does Pyramid need a server of its own to run?

No. The introductory example builds a WSGI application with a configurator and serves it with the standard library's simple server module on port 6543. The framework ships four console scripts instead: a development server, an interactive shell, and two introspection commands for routes and views.

### What does Pyramid depend on at runtime?

Nine packages, each carrying an inline comment in the manifest naming the feature it provides: WebOb for a request header method, zope.interface for its registry, venusian for an ignore decorator, hupper for ignore_files support, plaster plus a PasteDeploy integration for configuration, translationstring and zope.deprecation for Python 3 compatibility, and setuptools itself, capped below version 82 because pkg_resources is still required.

### Which Python versions does Pyramid support?

The manifest requires Python 3.10 or newer, and the classifiers name 3.10, 3.11, 3.12, 3.13 and 3.14, with both CPython and PyPy listed as supported implementations. The version on the main branch is 2.2.dev0, and the repository has no GitHub releases to pin.

### What licence is Pyramid released under?

A BSD-derived Repoze Public License. The manifest records it as a licence reference rather than a standard identifier, with the licence text in a separate named file, and there is a copyright file in the repository root. The readme credits a named consulting company and a team of contributors.

## Sources

- [Issues](https://github.com/Pylons/pyramid/issues)
- [Project website](https://trypyramid.com/)
- [Pylons/pyramid on GitHub](https://github.com/Pylons/pyramid)
- [README](https://github.com/Pylons/pyramid/blob/main/README.md)

---

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