Rely on infogami-style setup to avoid duplicate setup calls

[cdrini]

Closes #12034

This isn't ideal, but this setup pattern is used profusely and recursively throughout the codebase; including in infogami. To close the P0 and remove the risk of double-running sensitive internals, this seems like the quickest, simplest approach.

Technical

In infogami we often use a pattern like this to define an endpoint:

class scan(delegate.page):
    path = "/barcodescanner"

    def GET(self):
        return render.barcodescanner()

Sub-classing delegate.page is enough to register the endpoint. But if the file is never imported, that sub-classing never happens! So the pattern that infogami/webpy use is to have a setup method in the bottom of every file that contains endpoints, like this:

class scan(delegate.page):
    ...

def setup():
    # Importing calls _others'_ setup methods
    from openlibrary.plugins.worksearch import autocomplete

setup()

This is a problematic pattern, because it makes it incredibly easy to:

1. Forget to create this magic setup method, which would cause nothing to happen
2. Accidentally register another file's endpoints just by importing, and not include it in the setup method
3. Makes it impossible to import any methods/helpers without also registering endpoints

A better approach is to make it explicit, as #11762 does:

class scan(delegate.page):
    ...

def setup():
    from openlibrary.plugins.worksearch import autocomplete import setup as autocomplete_setup

    autocomplete_setup()

This decouples the setup from the import, but again still has the magic endpoint definition. And the new issue introduced is that we can now call these setup methods twice, resulting in undefined behaviour.

This is possibly also complicated by the @public decorator, which also requires being called at the correct point in the infogami import life-cycle.

Testing

No duplicate headers on testing or prod.

Screenshot

Stakeholders

[Copilot]

Pull request overview

Updates Open Library’s Infogami app initialization to avoid duplicate setup() execution by relying on module-import side effects (endpoint registration) instead of explicitly importing and calling plugin setup() functions.

Changes:

• Removes explicit setup imports for several plugins from openlibrary/code.py.
• Registers plugin endpoints by importing each plugin’s code module inside setup().

[Copilot]

These imports are only for side effects, but as written they will trigger Ruff F401 (unused import) for each line (only the last one is suppressed). Consider switching to importlib.import_module(...) calls (keeps explicit ordering without isort interference and avoids F401), or add # noqa: F401 to each import (and optionally combine with the existing I001 suppression if you’re intentionally keeping a non-isort order).

Suggested change

	import openlibrary.plugins.openlibrary.code # noqa: I001 registers endpoints
	import openlibrary.plugins.worksearch.code
	import openlibrary.plugins.inside.code
	import openlibrary.plugins.books.code
	import openlibrary.plugins.admin.code
	import openlibrary.plugins.upstream.code
	import openlibrary.plugins.openlibrary.code # noqa: I001, F401 registers endpoints
	import openlibrary.plugins.worksearch.code # noqa: F401 registers endpoints
	import openlibrary.plugins.inside.code # noqa: F401 registers endpoints
	import openlibrary.plugins.books.code # noqa: F401 registers endpoints
	import openlibrary.plugins.admin.code # noqa: F401 registers endpoints
	import openlibrary.plugins.upstream.code # noqa: F401 registers endpoints

[cdrini]

Unfortunately it won't let me do that. Not sure why. It gets reverted by (I think) ruff.

[RayBB]

Makes sense.
It's not ideal but needed for short term fixes.
Long term we'll naturally move away from these as we move towards fastapi.