Plugin Development

Daytona is a Dev Environment Manager. To extend its functionality, developers can create plugins. These plugins can be used to add support for new providers, builders, and IDEs.

Plugin Types

Plugins can be classified into three primary types:

• Providers: Implement functionality for interacting with external systems. They are responsible for managing resources and executing tasks in a specific environment.
• Builders: Define how a development environment is built and configured. They determine the tools, libraries, and configurations used within a workspace.
• IDE Plugins: Extend the integration with specific IDEs. They provide specific functionality and features for specific IDEs.

Example: Creating a New Provider

To create a new provider, the developer must implement the ProviderPlugin interface. The ProviderPlugin interface defines a set of functions that the provider must implement. These functions define the provider’s behavior for tasks such as creating a project, starting and stopping a workspace, and forwarding ports.

type ProviderPlugin interface {
              Initialize(InitializeProviderRequest) (util.Empty, error)
              CreateProject(ProjectRequest) (*util.Empty, error)
              StartProject(StartProjectRequest) (*util.Empty, error)
              StopProject(util.Empty) (*util.Empty, error)
              ProjectInfo(util.Empty) (*ProjectInfo, error)
              GetProjects(util.Empty) ([]*ProjectInfo, error)
              GetLogs(GetLogsRequest) (*util.LogsResponse, error)
              GetLogsForProject(GetLogsForProjectRequest) (*util.LogsResponse, error)
              UpdateLogsPath(UpdateLogsPathRequest) (*util.Empty, error)
              ForwardPort(ForwardPortRequest) (*util.Empty, error)
              ExecuteCommand(ExecuteCommandRequest) (*util.CommandResponse, error)
              SSH(util.Empty) (*util.Empty, error)
              DeleteProject(util.Empty) (*util.Empty, error)
              Close()
          }
          

Example: Creating a New Builder

To create a new builder, the developer must implement the BuilderPlugin interface. The BuilderPlugin interface defines a set of functions that the builder must implement. These functions define the builder’s behavior for tasks such as building a workspace, configuring the environment, and cleaning up the workspace.

type BuilderPlugin interface {
              Initialize(InitializeBuilderRequest) (util.Empty, error)
              Build(BuildRequest) (util.Empty, error)
              Cleanup(util.Empty) (util.Empty, error)
          }
          

Example: Creating an IDE Plugin

To create an IDE plugin, the developer must use a specific IDE’s plugin development framework. The specific framework depends on the IDE being targeted. For example, to create a plugin for Visual Studio Code, the developer would use the Visual Studio Code Extension API.

Building Plugins

Once a plugin is created, it must be built and packaged. The plugin’s packaging format depends on the IDE being targeted. For example, a plugin for Visual Studio Code would be packaged as a VSIX file.

Installing Plugins

Once a plugin is built and packaged, it can be installed into Daytona. To install a plugin, the developer must use the daytona provider command.

daytona provider install [PLUGIN_PATH]
          

Managing Plugins

The daytona provider command can be used to manage installed plugins. For example, the daytona provider list command can be used to list installed plugins.

daytona provider list
          

Using Plugins

Once a plugin is installed, it can be used in Daytona. The specific usage depends on the plugin type. For example, a new provider can be used to create a workspace by using the daytona create command. A new builder can be used to create a workspace by using the daytona create command with the --builder flag. An IDE plugin can be used to add functionality to the IDE.

Considerations for Plugin Development

• Plugin Structure: Organize your plugin’s code into logical modules and classes to improve maintainability and readability.
• Documentation: Ensure your plugin is well-documented with clear descriptions of its functionality, usage, and limitations.
• Testing: Thoroughly test your plugin to ensure it works correctly and meets the requirements.
• Compatibility: Consider the compatibility of your plugin with different versions of Daytona and the target IDE.
• Security: Implement appropriate security measures to protect your plugin and user data.

Top-Level Directory Explanations

hack/ - Directory for Go development, including build scripts and dependencies.

hack/builder_image/ - Subdirectory for building Docker images for Go development.

internal/ - Private package directory for the project’s internal modules.

internal/jetbrains/ - Subdirectory for JetBrains IDE integrations.

internal/testing/ - Subdirectory for testing-related modules.

internal/testing/logger/ - Subdirectory for logging configurations for tests.

pkg/ - Go packages directory.

pkg/ide/ - Subdirectory for IDE-related packages and scripts.

pkg/views/ - Subdirectory for view templates.

pkg/views/ide/ - Subdirectory for IDE view templates.