Components

In the VisionAppster platform, components are installable software modules. They serve about the same function as “packages” in a package manager such as npm, apt or yum. The Builder lets one to create components out of apps or manually crafted directory structures. There is also a command-line tool for building packages. Components can be installed locally and distributed through the VisionAppster Store.

Components can depend on each other. A typical case is an app component that depends on a tool plugin component. To ease managing dependencies, a component package can contain more than one component including their licenses, making the package self-contained.

Component ID

Each component has a component ID whose uniqueness is ensured by a convention: each seller chooses a namespace that is usually a reversed domain name such as com.visionappster. Within this namespace, the seller can easily ensure uniqueness of component names.

Component IDs can only contain lowercase letters (a-z) and digits (0-9). Dots (.) are used as part separators and must be surrounded by at least one valid name character on both sides. A component ID can be, for example com.visionappster.mvp. The minimum number of parts in a component ID is two.

It is important to understand that this is just a naming convention; no one checks that there is a domain that matches the namespace nor that it is owned by the owner of the component. The VisionAppster Store however ensures the uniqueness of component IDs when new components are registered. There is one exception to this rule: component IDs starting with system. are reserved for internal use.

Component version

Different versions of the same component are identified by a semantic version number. To ensure interoperability of components, the platforms follows the semantic versioning spec very carefully, and so must component owners.

A semantic version number has three parts: major.minor.patch. If a change in the component breaks existing functionality, the major version number must be incremented. Features can be added but not removed when changing the minor version number. If a release does not add new functionality but just improves or fixes the implementation, patch must be incremented. Version numbering can be started at any number, but usually 1.0.0 marks the first release. 0.0.0 is not allowed.

The most important rule component owners must follow is that all revisions within a major version must be backwards compatible. This makes it possible to upgrade depending components independently. Component licenses also apply to a major version.

Full component ID

Multiple major versions of the same component can coexist. Therefore, the platform uses a full component ID to identify components. The full component ID is formed by concatenating the ID and major version number of a component, e.g. system.tools/3.

Component name

In addition to the component ID, each component distributed through the VisionAppster Store must have a human-readable name. The name is optional if a component is built for local use only, but it is still useful as the component IDs are not too user-friendly. The component name is for marketing and informational purposes only and does not need to be unique.

External dependencies

Components can depend on external software packages such as Python modules in the Python package index (PyPI). Such packages are distinguished by a scheme at the beginning of the component id. For example, practically all components containing Python code depend on NumPy. The name of the NumPy package in PyPI is numpy and the scheme for Python packages is python. The component ID for NumPy thus becomes python:numpy.

VisionAppster cannot enforce semantic versioning requirements to external dependencies nor make sure multiple versions of them will work simultaneously. Python is especially notorious with its virtual environments. Therefore, only one version of an external dependency can be installed and versioned (full) component IDs do not apply to them. In other words, python:numpy always refers to the currently installed version of NumPy, independent of its version number.