You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenShell has Snap packaging in the repo, but the user-facing Snap path is not complete. The current snapcraft.yaml has only a short Store description, the installation docs do not mention Snap, and install.sh does not prefer Snap on Linux systems where snapd is already available.
Maintainer discussion identified several Snap-specific gaps:
Put basic usage instructions in the Snap description text in snapcraft.yaml so the Store page updates from the repo metadata.
Verify whether the current Snap Store declaration allows the required connections for the current strict snap.
Move Store-managed visual metadata into the repo, including a logo/icon under meta/gui/ when Snapcraft conventions allow it.
Add a desktop launcher that can be searched from desktop environments and runs the OpenShell terminal UI, likely openshell term, through the platform terminal.
Update the published installation docs at docs/about/installation.mdx with Snap instructions.
Consider updating install.sh to install through Snap when snapd is available, while preserving native package fallbacks.
Proposed Design
Update the Snap packaging and docs as one user-facing installation path:
Update snapcraft.yaml description text with concise basic usage instructions for Snap users, including Docker snap setup, interface connection commands, gateway creation or verification commands, and links back to the docs.
Audit the current strict-confinement plugs and Store declaration behavior for docker, network, network-bind, log-observe, ssh-keys, system-observe, and any other required interface. Document which connections are automatic and which require manual snap connect commands.
Add repo-managed Snap GUI metadata under meta/gui/, including the OpenShell logo/icon. If appropriate, add a .desktop launcher that starts the OpenShell terminal UI in the default platform terminal so OpenShell is discoverable from Linux desktop search.
Update docs/about/installation.mdx with a Snap section covering install, required Docker setup/connections, gateway status checks, and when users should choose Snap versus native DEB/RPM packages.
Update install.sh so Linux systems with snapd available can use the Snap path by default, with clear fallback behavior for unsupported systems, version-pinned installs, or users who need native packages.
Store-only metadata updates were considered, but keeping description and visual metadata in snapcraft.yaml/meta/gui/ makes Store updates reproducible and versioned with the package.
Leaving install.sh on DEB/RPM only was considered, but Snap can provide a simpler install path on snap-enabled Linux systems. Native packages should remain available as fallbacks and for distributions or workflows where Snap is not appropriate.
Splitting this into separate docs and packaging issues was considered. A single issue is useful because the Store description, interface guidance, desktop metadata, docs page, and installer selection all describe the same Snap installation experience.
Agent Investigation
Loaded the create-github-issue skill and followed the repo feature-request format.
Reviewed .github/ISSUE_TEMPLATE/feature_request.yml and confirmed feature requests require Problem Statement, Proposed Design, Alternatives Considered, and optional Agent Investigation.
Reviewed snapcraft.yaml; it currently defines the openshell and gateway apps, strict confinement, and plugs including docker, network, network-bind, log-observe, ssh-keys, and system-observe, but the description is a short product summary.
Reviewed docs/about/installation.mdx; it documents curl/native package installation, macOS Homebrew, Linux DEB/RPM packages, and Kubernetes, but not Snap.
Searched for Snap references and found docs/reference/gateway-config.mdx mentions Snap gateway config path, but installation docs and install.sh do not currently expose Snap as an install path.
Problem Statement
OpenShell has Snap packaging in the repo, but the user-facing Snap path is not complete. The current
snapcraft.yamlhas only a short Store description, the installation docs do not mention Snap, andinstall.shdoes not prefer Snap on Linux systems where snapd is already available.Maintainer discussion identified several Snap-specific gaps:
snapcraft.yamlso the Store page updates from the repo metadata.meta/gui/when Snapcraft conventions allow it.openshell term, through the platform terminal.docs/about/installation.mdxwith Snap instructions.install.shto install through Snap when snapd is available, while preserving native package fallbacks.Proposed Design
Update the Snap packaging and docs as one user-facing installation path:
snapcraft.yamldescription text with concise basic usage instructions for Snap users, including Docker snap setup, interface connection commands, gateway creation or verification commands, and links back to the docs.docker,network,network-bind,log-observe,ssh-keys,system-observe, and any other required interface. Document which connections are automatic and which require manualsnap connectcommands.meta/gui/, including the OpenShell logo/icon. If appropriate, add a.desktoplauncher that starts the OpenShell terminal UI in the default platform terminal so OpenShell is discoverable from Linux desktop search.docs/about/installation.mdxwith a Snap section covering install, required Docker setup/connections, gateway status checks, and when users should choose Snap versus native DEB/RPM packages.install.shso Linux systems with snapd available can use the Snap path by default, with clear fallback behavior for unsupported systems, version-pinned installs, or users who need native packages.Alternatives Considered
Store-only metadata updates were considered, but keeping description and visual metadata in
snapcraft.yaml/meta/gui/makes Store updates reproducible and versioned with the package.Leaving
install.shon DEB/RPM only was considered, but Snap can provide a simpler install path on snap-enabled Linux systems. Native packages should remain available as fallbacks and for distributions or workflows where Snap is not appropriate.Splitting this into separate docs and packaging issues was considered. A single issue is useful because the Store description, interface guidance, desktop metadata, docs page, and installer selection all describe the same Snap installation experience.
Agent Investigation
create-github-issueskill and followed the repo feature-request format..github/ISSUE_TEMPLATE/feature_request.ymland confirmed feature requests require Problem Statement, Proposed Design, Alternatives Considered, and optional Agent Investigation.snapcraft.yaml; it currently defines theopenshellandgatewayapps, strict confinement, and plugs includingdocker,network,network-bind,log-observe,ssh-keys, andsystem-observe, but the description is a short product summary.docs/about/installation.mdx; it documents curl/native package installation, macOS Homebrew, Linux DEB/RPM packages, and Kubernetes, but not Snap.docs/reference/gateway-config.mdxmentions Snap gateway config path, but installation docs andinstall.shdo not currently expose Snap as an install path.Checklist