Implement briefcase publish web for PythonAnywhere

[filiplajszczak]

Summary

Implement the pythonanywhere publication channel for briefcase publish web,
allowing users to deploy a built static web app to PythonAnywhere with a single command.

Background

The StaticWebPublishCommand already exists as a placeholder with s3 as the default (and only)
publication channel, but publish_app() is currently not implemented.
I'm happy to prepare the issue and later PR once the final shape is agreed upon.
The scaffolding was discussed in person with @freakboy3742 but let's reiterate here and discuss some detail.

Proposed Behavior

Running briefcase publish web would:

1. Check that API_TOKEN is set via self.tools.os.environ,
   following the existing briefcase practice for accessing environment variables.
2. Read the PythonAnywhere username from the app config in pyproject.toml
   (e.g., pythonanywhere_username under the web platform section) and set
   PYTHONANYWHERE_USERNAME in the environment before importing pythonanywhere-core,
   as the library uses this to construct API endpoints at class instantiation time.
3. Upload files from the built www directory to PythonAnywhere using the
   Files API (recursive directory upload).
4. Create the web app on PythonAnywhere.
5. Set a static file mapping from / to the uploaded directory.
6. Reload the web app for the static mapping to take effect.

Configuration

Users would add their PythonAnywhere username to pyproject.toml:

[tool.briefcase.app.myapp.web]
pythonanywhere_username = "myuser"

The resulting site would be available at myuser.pythonanywhere.com.

Dependencies

This relies on pythonanywhere-core,
which has been updated with the necessary features:

• Files.tree_post() for recursive directory upload
• Webapp.create() now accepts virtualenv_path=None for static sites
• PYTHONANYWHERE_USERNAME env var support for running outside PythonAnywhere

pythonanywhere-core would be an optional dependency, installed via briefcase[pythonanywhere].

Documentation

This would include documentation for the publish command with PythonAnywhere configuration. Could this also be included in the Briefcase tutorial? PythonAnywhere's free tier would make it an accessible way for new users to deploy their first web app.

Open Questions

• The base PublishCommand.__call__() already checks that the app has been built (binary_path exists) and raises an error if not. _publish_app() has a TODO to verify the app has been packaged. Should publish auto-trigger a build if the app hasn't been built yet, or continue to require the user to build first?
• Should the existing placeholder s3 channel, which has no implementation, be removed as part of this work?
• Is pythonanywhere_username the right config key, and is [tool.briefcase.app.myapp.web] the right section for it? When running on PythonAnywhere itself, the username is already available in the environment — should briefcase detect this and only require the config key when running locally?
• Should the command behave differently when running on PythonAnywhere vs locally? When running on PythonAnywhere, the file upload (step 3) could be skipped and the static file mapping (step 5) could point directly to the local build directory.
• Should API_TOKEN be the only supported way to provide credentials, or should there be an alternative (e.g., prompting the user interactively)?
• Is briefcase[pythonanywhere] the right extra name for the optional dependency?
• Should PYTHONANYWHERE_CLIENT be set to briefcase/{version} so API requests are identifiable?

Platform Considerations

This only affects the web/static platform — no impact on other platforms. PythonAnywhere provides free-tier hosting, making it a practical default channel for deploying Briefcase web apps.

[freakboy3742]

Thanks for starting this discussion, @filiplajszczak!

The publish command has been there in stub form for a long time; I'd very much like to see it have an actual use, and a PythonAnywhere publication channel for the web backend is as good a place as any to start (if only because there's a very clear deployment story to be told).

Some additional thoughts and suggestions:

• We probably want to make the definition of a packaging channel a plugin interface, so that third parties can define their own publication channels without them being part of Briefcase itself. We already do this for individual platforms; extending the plugin interface to add publication channels would follow a similar pattern. The plugin interface doesn't have to be any more complicated than "defines publish_app() (or similar), with the same API as the class currently uses", but it should exist.

• It might be worth explicitly packaging the pythonanywhere publication channel as a standalone package as a proof of concept - at the very least, that would avoid any issues around adding pythonanywhere_core as a requirement, because it would only be a requirement of the plugin if it were installed. I'm not completely sure if that's more effort than it's worth, though.

• Regardless of whether it's a completely standalone package or baked into Briefcase itself, it should be possible to run Briefcase without having the pythonanywhere_core package installed. You should only get an error if you try to publish to PythonAnywhere and don't have the package available.

• How rigorous does our "safety" story need to be around manual confirmation of overwriting existing deployments? Should any publish call destroy any existing deployment at the same address? Do we need to have an explicit --create option for first publication (which won't do anything destructive on an existing configuration)? Is there any way to gracefully roll over from v1 to v2 of an app deployment? Is it necessary to delete the old app and re-deploy, or is there a reasonable mechanism for updating an existing deployment?

• Based on the experimentation we've done over the last couple of days, getting a progress indicator on the file upload would be a nice win, but not necessarily required. I know the PA Files API has a "tree upload" option; if adding a progress indicator doesn't make sense to add to that API, Briefcase's built-in progress indicators could be used in conjunction with a tree walk and a single file upload option.

Regarding the open questions:

Could this also be included in the Briefcase tutorial? PythonAnywhere's free tier would make it an accessible way for new users to deploy their first web app.

I agree this would make sense once the implementation is in place and available in a public release

Should publish auto-trigger a build if the app hasn't been built yet, or continue to require the user to build first?

Yes - this should definitely happen

• Should the existing placeholder s3 channel, which has no implementation, be removed as part of this work?

Yes - that would make sense. This would effectively end up a consequence of there being no registered plugin implementation for s3.

• Is pythonanywhere_username the right config key, and is [tool.briefcase.app.myapp.web] the right section for it? When running on PythonAnywhere itself, the username is already available in the environment — should briefcase detect this and only require the config key when running locally?

Given that PythonAnywhere will have a number of configuration settings, I'd suggest using a full table for configuration, rather than a bunch of long individual setting names - e.g.:

[tool.briefcase.app.myapp.web.pythonanywhere]
username = "myuser"
domain = "..."
...

I don't know if the use case of running on PythonAnywhere is especially likely - but if it's easy enough to accomodate by having a fallback value if you can identify that the code is running on PythonAnywhere, then we might as well support that.

• Should the command behave differently when running on PythonAnywhere vs locally? When running on PythonAnywhere, the file upload (step 3) could be skipped and the static file mapping (step 5) could point directly to the local build directory.

Again, I'm not sure how likely the "running on PythonAnywhere" use case actually is - but if it's easy enough to accomodate, then we might as well do so.

• Should API_TOKEN be the only supported way to provide credentials, or should there be an alternative (e.g., prompting the user interactively)?

There's potentially some overlap with #2279. While we don't want to encourage storing API tokens in pyproject.toml, it would be nice to have the option to store a token in a user configuration file. However, in the short term, environment variable based handling should be fine.

• Is briefcase[pythonanywhere] the right extra name for the optional dependency?

That seems as good as any - unless we go down the path of making briefcase-pythonanywhere a full standalone package.

• Should PYTHONANYWHERE_CLIENT be set to briefcase/{version} so API requests are identifiable?

If that's helpful for diagnostic purposes, then we might as well.

[filiplajszczak]

Thanks for the detailed feedback, @freakboy3742!

• We probably want to make the definition of a packaging channel a plugin interface, so that third parties can define their own publication channels without them being part of Briefcase itself. We already do this for individual platforms; extending the plugin interface to add publication channels would follow a similar pattern. The plugin interface doesn't have to be any more complicated than "defines publish_app() (or similar), with the same API as the class currently uses", but it should exist.
• It might be worth explicitly packaging the pythonanywhere publication channel as a standalone package as a proof of concept - at the very least, that would avoid any issues around adding pythonanywhere_core as a requirement, because it would only be a requirement of the plugin if it were installed. I'm not completely sure if that's more effort than it's worth, though.

I like the plugin idea very much. As Briefcase already has a well-established plugin pattern, so
publication channels could follow the same approach.

Entry point group

A third-party package (e.g., briefcase-pythonanywhere) would register itself via:

[project.entry-points."briefcase.publication_channels"]
pythonanywhere = "briefcase_pythonanywhere:PythonAnywhereChannel"

Discovery

Following the pattern in src/briefcase/platforms/__init__.py and src/briefcase/debuggers/__init__.py:

from importlib.metadata import entry_points

def get_publication_channels():
    return {
        entry_point.name: entry_point.load()
        for entry_point in entry_points(group="briefcase.publication_channels")
    }

Base class

Similar to BaseDebugger in src/briefcase/debuggers/base.py — a minimal abstract base class that channel plugins must implement:

class BasePublicationChannel(ABC):
    @property
    @abstractmethod
    def name(self) -> str:
        """The human-readable name of this channel."""

    @abstractmethod
    def publish_app(self, app: AppConfig, command: PublishCommand, **options):
        """Publish an application.

        :param app: The application to publish
        :param command: The PublishCommand instance (provides console, tools, project_path, etc.)
        """

The command parameter gives the plugin access to briefcase internals it needs — command.tools.os.environ for environment variables, command.project_path(app) for the build directory, command.console for user output, etc.

Changes to PublishCommand

The current PublishCommand has hardcoded publication_channels and default_publication_channel properties returning ["s3"] and "s3". These would be replaced with dynamic discovery:

• publication_channels calls get_publication_channels() to list what's installed
• publish_app() delegates to the discovered channel plugin
• If no channels are installed, or the requested channel isn't found, a helpful error message is shown
• The s3 placeholder goes away naturally.

Auto-build

Agreed that publish should trigger a build if the app hasn't been built. The current __call__() raises BriefcaseCommandError when binary_path doesn't exist — this could be changed to invoke the build command instead.

Open questions

• Should channels declare which platforms/formats they support? PythonAnywhere is web-only, App Store would be iOS/macOS-only. Or is that left to the plugin to validate at publish time?
• Should there be a --channel default when only one channel is installed, or should the user always specify it explicitly?
• The current _publish_app() runs pre-checks (verify_app, plus a TODO for packaging verification) before delegating to publish_app(). In the plugin system, should this orchestration stay in briefcase core (so plugins only handle the actual publishing), or should plugins be responsible for their own pre-flight checks?
• Should briefcase publish -h list available publication channels? Debuggers already do this — get_debuggers() dynamically populates --debug choices at parse time, so help shows what's installed. The same pattern could work for --channel.

Next steps

Since the scope has shifted from PythonAnywhere-specific publishing to a general plugin interface, should we start a new dedicated discussion for the publication channel plugin system, or continue here?

Once we have consensus on the plugin interface shape, I'll create an issue for it. The PythonAnywhere-specific questions (safety/overwrite story, progress indicators, config structure) can be discussed separately in the context of briefcase-pythonanywhere as a standalone package.

[freakboy3742]

Entry point group

A third-party package (e.g., briefcase-pythonanywhere) would register itself via:

[project.entry-points."briefcase.publication_channels"]
pythonanywhere = "briefcase_pythonanywhere:PythonAnywhereChannel"

I'd be inclined to make this entry-point do double service, and declare availability of both the channel and the deployment target:

[project.entry-points."briefcase.publication_channels.web.static"]
pythonanywhere = "briefcase_pythonanywhere:PythonAnywhereChannel"

If a publication channel works for multiple deployment formats (which is likely for desktop platforms - macOS will produce DMGs regardless of whether you use the app or Xcode backend), then you could register it twice.

Discovery

Following the pattern in src/briefcase/platforms/__init__.py and src/briefcase/debuggers/__init__.py:

Agreed that this is the general pattern we should follow; although we'll need to pass in the platform and format if we use the registration pattern described above.

Base class

Similar to BaseDebugger in src/briefcase/debuggers/base.py — a minimal abstract base class that channel plugins must implement:
...
@AbstractMethod
def publish_app(self, app: AppConfig, command: PublishCommand, **options):
"""Publish an application.

Agreed on this general shape.

One thing that occurs to me is that we may also need to pass in a packaging format to this command. This doesn't really impact web deployment, as there's really only one packaging format (a zip file); but desktop platforms can support multiple packaging formats (e.g., PKG, DMG and APP on macOS). There will only ever be a single file, but the name of that file (and some details of the packaging process) might change depending on the format chosen.

As an aside, the packaging formats should probably also be handled as plugins... that would allow someone to write an NSIS installer for Windows without us needing to take responsibility for that. That can be a completely separate effort to adding pluggable publication, though.

The command parameter gives the plugin access to briefcase internals it needs — command.tools.os.environ for environment variables, command.project_path(app) for the build directory, command.console for user output, etc.

I agree that command needs to be an argument to the plugin call, but we will need to be explicit about what methods on that command are part of the API guarantee. There are some internal methods that we may not want to commit to supporting indefinitely without backwards-incompatible changes. Part of the process of implementing this will need to be documentation of what an external publication provider can rely on as part of the PublishCommand interface. I'm happy for that to be something that we develop iteratively as we build a "real" publication backend, rather than something we explicitly design up front.

Changes to PublishCommand

The current PublishCommand has hardcoded publication_channels and default_publication_channel properties returning ["s3"] and "s3". These would be replaced with dynamic discovery:

• publication_channels calls get_publication_channels() to list what's installed
• publish_app() delegates to the discovered channel plugin
• If no channels are installed, or the requested channel isn't found, a helpful error message is shown
• The s3 placeholder goes away naturally.

+1

Auto-build

Agreed that publish should trigger a build if the app hasn't been built. The current __call__() raises BriefcaseCommandError when binary_path doesn't exist — this could be changed to invoke the build command instead.

I suspect it might need to be the "package" command, not publish - but yes. package should trigger a build if one doesn't exist (and the logic that exists for that is a convenient model for what publish will need to do the next level up).

Open questions

• Should channels declare which platforms/formats they support? PythonAnywhere is web-only, App Store would be iOS/macOS-only. Or is that left to the plugin to validate at publish time?

I think this should be resolved by the explicit registration approach.

• Should there be a --channel default when only one channel is installed, or should the user always specify it explicitly?

If there's only 1 channel, I agree it would make sense to publish to that channel without the need to be explicit; as soon as there's more than one, you should need to be explicit.

It might make sense to allow the project to configure a preferred publication channel, so that if you don't specify a channel, the pyproject.toml defines the preferred channel. That would allow you to say "We're deploying to PythonAnywhere" as a project-level configuration, which I suspect will be what is required anyway. That might make sense to do as part of work on #2279.

• The current _publish_app() runs pre-checks (verify_app, plus a TODO for packaging verification) before delegating to publish_app(). In the plugin system, should this orchestration stay in briefcase core (so plugins only handle the actual publishing), or should plugins be responsible for their own pre-flight checks?

I'd say the plugin should be able to assume it's been given a fully verified, validated app; with the core providing that logic.

• Should briefcase publish -h list available publication channels? Debuggers already do this — get_debuggers() dynamically populates --debug choices at parse time, so help shows what's installed. The same pattern could work for --channel.

If we can incorporate available plugins into help text, I agree that would be desirable.

Next steps

Since the scope has shifted from PythonAnywhere-specific publishing to a general plugin interface, should we start a new dedicated discussion for the publication channel plugin system, or continue here?

I don't think a different discussion is needed. Yes, a plugin interface is broader scope than the originally proposal, but it's in the same general vein; until we get to the point of a finalized design that is solidified as a ticket, I'm OK with continuing the discussion here.

[filiplajszczak]

Working through each remaining point:

Entry point scoping

I'd be inclined to make this entry-point do double service, and declare availability of both the channel and the deployment target:

[project.entry-points."briefcase.publication_channels.web.static"]
pythonanywhere = "briefcase_pythonanywhere:PythonAnywhereChannel"

If a publication channel works for multiple deployment formats (which is likely for desktop platforms - macOS will produce DMGs regardless of whether you use the app or Xcode backend), then you could register it twice.

Agreed, this is a clean way to handle it.

Agreed that this is the general pattern we should follow; although we'll need to pass in the platform and format if we use the registration pattern described above.

Right. Discovery would become something like:

def get_publication_channels(platform, format):
    return {
        entry_point.name: entry_point.load()
        for entry_point in entry_points(
            group=f"briefcase.publication_channels.{platform}.{format}"
        )
    }

following the same approach as get_output_formats(platform) in src/briefcase/platforms/__init__.py.

Packaging format

One thing that occurs to me is that we may also need to pass in a packaging format to this command. This doesn't really impact web deployment, as there's really only one packaging format (a zip file); but desktop platforms can support multiple packaging formats (e.g., PKG, DMG and APP on macOS).

I'd apply YAGNI here. The entry point registration already scopes by platform and format, so the plugin knows what context it's operating in. The command object exposes project_path(app) and distribution_path(app) for concrete file paths. If a plugin ever needs to know the packaging format by name, command.output_format could be available.

Command API surface

I agree that command needs to be an argument to the plugin call, but we will need to be explicit about what methods on that command are part of the API guarantee. There are some internal methods that we may not want to commit to supporting indefinitely without backwards-incompatible changes.

Maybe we can use a typing protocol to define the stable API boundary for the
command parameter:

class PublishCommandAPI(Protocol):
    @property
    def console(self) -> Console: ...
    @property
    def tools(self) -> ToolCache: ...
    def project_path(self, app: AppConfig) -> Path: ...       # build tree
    def distribution_path(self, app: AppConfig) -> Path: ...  # packaged artifact

The plugin's publish_app() would be typed as receiving PublishCommandAPI rather than PublishCommand. This makes the API boundary explicit at the type level — what's in the Protocol is the stable contract, everything else is internal. It could start minimal and grow iteratively as actual plugins reveal what they need.

Auto-package, direct deployment, and _publish_app() orchestration

I suspect it might need to be the "package" command, not publish - but yes. package should trigger a build if one doesn't exist (and the logic that exists for that is a convenient model for what publish will need to do the next level up).

I'd say the plugin should be able to assume it's been given a fully verified, validated app; with the core providing that logic.

Agreed on both. The chain is publish -> package -> build, and PackageCommand._package_app() already handles the auto-build decision tree.

That said, I see two deployment models:

• Artifact model (e.g., App Store): build -> package (create .dmg/.pkg) -> publish (upload artifact)
• Direct deployment model (e.g., PythonAnywhere): build -> publish (upload built files directly)

For web/static, package creates a zip file. For PythonAnywhere the zip is an unnecessary intermediate step.

To handle this, the channel could declare what preparation level it requires:

class BasePublicationChannel(ABC):
    @property
    def requires_packaging(self) -> bool:
        return True  # default for most channels?

Then _publish_app() stays on PublishCommand, handles all pre-flight based on the channel's declaration, and the plugin only implements the actual publishing logic:

def __call__(self, channel=None, **options):
    self.finalize(apps=self.apps.values())
    channels = get_publication_channels(platform, format)
    channel_plugin = channels[channel]  # + error handling

    for app_name, app in sorted(self.apps.items()):
        self._publish_app(app, channel_plugin, **options)

def _publish_app(self, app, channel_plugin, **options):
    if channel_plugin.requires_packaging:
        # ensure packaged (auto-package -> auto-build if needed)
    else:
        # ensure built (auto-build if needed)

    self.verify_app(app)
    channel_plugin.publish_app(app, command=self, **options)

PythonAnywhere would set requires_packaging = False and work with command.project_path(app).

Does this distinction make sense, or should all channels go through the full package step?

Default channel

If there's only 1 channel, I agree it would make sense to publish to that channel without the need to be explicit; as soon as there's more than one, you should need to be explicit.

Agreed.

It might make sense to allow the project to configure a preferred publication channel, so that if you don't specify a channel, the pyproject.toml defines the preferred channel.

Makes sense as a follow-on. The [tool.briefcase.app.myapp.web.pythonanywhere] config already implies a channel choice — a default_channel key at the format level would formalize it.

Do you know if #2494 (review resolution pending since October) is still being worked on? The .briefcase/config.toml it introduces would also be the natural home for API tokens. We don't need to block on it, but worth keeping the publication channel design compatible with that direction.

Next steps

The open questions I see are:

1. requires_packaging on channels — does the direct deployment model (skip packaging) make sense as part of the base interface?
2. Anything else needed around BasePublicationChannel before starting on specification in the dedicated issue?

When we have that I'll put together an implementation PR for the plugin interface in briefcase, and then build briefcase-pythonanywhere against it. Bit of yak shaving ahead, but it looks like we will be able to do it properly.

[freakboy3742]

Packaging format

One thing that occurs to me is that we may also need to pass in a packaging format to this command. This doesn't really impact web deployment, as there's really only one packaging format (a zip file); but desktop platforms can support multiple packaging formats (e.g., PKG, DMG and APP on macOS).

I'd apply YAGNI here. The entry point registration already scopes by platform and format, so the plugin knows what context it's operating in. The command object exposes project_path(app) and distribution_path(app) for concrete file paths. If a plugin ever needs to know the packaging format by name, command.output_format could be available.

Agreed that YAGNI is always a good principle to follow if we can. The confusion on my part came because I was recalling that distribution_path() took a packaging_format argument on some platforms. I was misremembering - packaging_format is set as a property during the configuration of apps. This means that, on platforms where it matters, the -p/--packaging-format argument will need to be exposed as part of the publish command; but the API for publishing won't need an explicit API entry point.

Command API surface

Maybe we can use a typing protocol to define the stable API boundary for the command parameter:

Agreed this would be a good way to approach the problem.

Auto-package, direct deployment, and _publish_app() orchestration

That said, I see two deployment models:

• Artifact model (e.g., App Store): build -> package (create .dmg/.pkg) -> publish (upload artifact)
• Direct deployment model (e.g., PythonAnywhere): build -> publish (upload built files directly)

For web/static, package creates a zip file. For PythonAnywhere the zip is an unnecessary intermediate step.

Agreed it's strictly unnecessary - but I think might be beneficial to go through the ZIP motions regardless.

Firstly, if we are able to push a single ZIP file to PythonAnywhere and unpack it as part of the deploy process, that simplifies the artefact upload (and might even make it smaller? I'm not sure how much on-the-wire compression the PythonAnywhere API does).

Secondly, "what is in the ZIP file" becomes a useful audit point for what is actually published. Even if we don't send the ZIP file on the wire, if we read directly from the ZIP file contents and only send the stuff that is in the zip, we can differentiate between "These are files that are in the build folder at time of archival" and "these are the files I actually want on the server". For example, we could exclude __pycache__ files from the ZIP archive, making for a smaller transmission as part of deployment.

Do you know if #2494 (review resolution pending since October) is still being worked on? The .briefcase/config.toml it introduces would also be the natural home for API tokens. We don't need to block on it, but worth keeping the publication channel design compatible with that direction.

I think progress on #2494 is mostly stalled at this time; agreed that work on #2494 doesn't need to block work on this feature, though.

Next steps

The open questions I see are:

1. requires_packaging on channels — does the direct deployment model (skip packaging) make sense as part of the base interface?

I think this is a two questions are resolved by using the "read from artefact" approach to publication for the web case - but happy to revisit if you think that approach won't work.

2. Anything else needed around BasePublicationChannel before starting on specification in the dedicated issue?

Not that I can think of - I think the design we've got here is fairly solid at this point. I'm happy for this to proceed to a feature enhancement ticket.

When we have that I'll put together an implementation PR for the plugin interface in briefcase, and then build briefcase-pythonanywhere against it. Bit of yak shaving ahead, but it looks like we will be able to do it properly.

One more unresolved question: where will briefcase-pythonanywhere live? Is it an external thing that PythonAnywhere owns, or is it part of this repo? I'm happy for it to live here - if nothing else, it means we can ensure it remains tested and in sync.

If it does live here, do we need to do some reorganisation and add an "extras" folder where things like debugger, automation, and PythonAnywhere plugins live? If we're going to end up with multiple deployment plugins, we probably want to avoid having dozens of top-level directories.

[filiplajszczak]

Packaging as source of truth

Firstly, if we are able to push a single ZIP file to PythonAnywhere and unpack it as part of the deploy process, that simplifies the artefact upload (and might even make it smaller? I'm not sure how much on-the-wire compression the PythonAnywhere API does).

There's no straightforward way to trigger a remote unzip on PythonAnywhere via the API, so the deployment would still be individual file uploads.

Secondly, "what is in the ZIP file" becomes a useful audit point for what is actually published. Even if we don't send the ZIP file on the wire, if we read directly from the ZIP file contents and only send the stuff that is in the zip, we can differentiate between "These are files that are in the build folder at time of archival" and "these are the files I actually want on the server".

Agreed — using the ZIP contents to determine which files to upload (rather than walking the build directory directly) makes sense as a clean boundary between "what was packaged" and "what happens to be in the build tree". That resolves the requires_packaging question — all channels go through packaging, and the plugin reads from the artifact.

For example, we could exclude __pycache__ files from the ZIP archive, making for a smaller transmission as part of deployment.

Is __pycache__ actually expected to appear in project_path for a static web site? Looking at a built web/static project, the www/ directory contains index.html, pyscript.toml, CSS, images, and .whl files — no .py files or __pycache__ at all. If that's somehow ending up in the build tree, it might be worth investigating separately. Either way, the "read from ZIP" approach handles it.

Where briefcase-pythonanywhere lives

One more unresolved question: where will briefcase-pythonanywhere live? Is it an external thing that PythonAnywhere owns, or is it part of this repo?

My initial inclination is that it could live under the pythonanywhere GitHub org in a separate repo, since it's specific to PythonAnywhere as a deployment target. PythonAnywhere would own maintenance and releases, and it keeps the briefcase repo focused on core functionality.

I'm happy for it to live here - if nothing else, it means we can ensure it remains tested and in sync.

I can see the argument for keeping it here. Happy to be convinced either way.

If it does live here, do we need to do some reorganisation and add an "extras" folder where things like debugger, automation, and PythonAnywhere plugins live? If we're going to end up with multiple deployment plugins, we probably want to avoid having dozens of top-level directories.

Something like plugins/ or extras/ containing various optional packages each as their directory with independent dependencies. Directory structure like that might may sense even if birefcase-pythonanywhere lives in its own repo. On the other hand, it looks like the current Beeware structure seems to keep separate repos for various packages, but maybe it's just my cursory glance.

Next steps

I'll put together the feature enhancement ticket for the publication channel plugin interface based on what we've agreed here. Once that's in place, the PythonAnywhere plugin can be built against it regardless of where it ends up living.

[freakboy3742]

For example, we could exclude __pycache__ files from the ZIP archive, making for a smaller transmission as part of deployment.

Is __pycache__ actually expected to appear in project_path for a static web site? Looking at a built web/static project, the www/ directory contains index.html, pyscript.toml, CSS, images, and .whl files — no .py files or __pycache__ at all. If that's somehow ending up in the build tree, it might be worth investigating separately. Either way, the "read from ZIP" approach handles it.

In a web project, you shouldn't see any __pycache__ files; I was using that more as an example of something that you might want to consider non-packaged content in some cases.

Where briefcase-pythonanywhere lives

One more unresolved question: where will briefcase-pythonanywhere live? Is it an external thing that PythonAnywhere owns, or is it part of this repo?

My initial inclination is that it could live under the pythonanywhere GitHub org in a separate repo, since it's specific to PythonAnywhere as a deployment target. PythonAnywhere would own maintenance and releases, and it keeps the briefcase repo focused on core functionality.

If you/PythonAnywhere is happy to take ownership of the package, I'm happy for it to live outside the BeeWare repo.

[filiplajszczak]

The plugin interface was implemented in #2701, and the original proposal has been realized as pythonanywhere-briefcase-plugin. With #2720 and beeware/beeware-tutorial#63, the plugin is also mentioned in Briefcase docs and the BeeWare tutorial. Once both documentation PRs are merged, I believe this discussion can be closed.