Django templates, edited where they render

One entry in INSTALLED_APPS: "portbay_loc". That is the whole configuration. Note the two names differ — the distribution you pip install is portbay-django-stamper with hyphens, and the importable app you register is portbay_loc with an underscore. Installing without registering is the one failure mode that looks like nothing happening, because Django has no package auto-discovery to fall back on.

No, deliberately. Shipping a template loader would have forced you to spell out OPTIONS['loaders'] by hand, which means deleting APP_DIRS and writing out the stock loaders yourself — a settings block you would then maintain forever, and one that silently changes template resolution order if you get it wrong. Instead the package patches the single Template constructor that every loader ends up calling, so your loaders and APP_DIRS stay exactly as they are.

Yes, and each element points at the file it was actually written in rather than the file it rendered through. A block defined in a child template and rendered into a base points at the child; an included partial points at the partial. On served HTML measured against a zero-stamp control, 18 of 18 coordinates were exact on both Django 6.1 and 5.2.17, covering an extends base, a child block, an included partial and a for loop over an include.

Yes. An htmx fragment is markup your server rendered through the same stamped templates, so the coordinates travel with the response — an htmx-style fragment measured 2 of 2 exact in the same run. Fragments assembled on the client, which the server never saw, are a different matter and fall back to text search.

Templates that are not .html or .htm, templates with no file behind them, and templates that live outside your project — a third-party app's templates get no coordinate. The reasoning is that a coordinate pointing into a file you cannot edit is worse than no coordinate at all, so those elements fall back to the text-search tier instead of claiming a precision they do not have.

No. The stamp is applied to the template source as a string in memory, on its way into Django's Template constructor — the file on disk is never opened for writing, so no data-pb-loc attribute ever reaches your repository. Stamping is on when DEBUG is on, and PORTBAY_LOC=0 or 1 overrides it either way; the shell form works, because manage.py runserver passes its whole environment through to the child process.

No. It is a Pro feature, still in early access behind an opt-in toggle in Settings, and it is not compiled into the open-source build at all. It is also unavailable on a project while that project is publicly tunneled — the edit bar and its write-back endpoints are never routed onto public traffic. Running Django, the database, the .test hostname and trusted HTTPS are all in the free, open-source app.