pvc

Writing new module files to support new repository types

Although the range of repositories already supported by PVC’s built in modules may be sufficient for most needs, it’s quite possible that additional repository support is needed. This is possible at the user level i.e. without integration into the main PVC application, by the creation of new module files to support other repository types. A repository type is just a label to denote how a particular repository presents its data. GitHub presents its data differently to Sourceforge so we give them different type labels: github and sourceforge respectively. Many repositories host multiple projects and, for purposes of network access, we distinguish between them by a urlbase which is generally the minimum part of the project’s url that is needed to distinguish that project from other projects at the same repository. Consider these three project urls:

    https://github.com/OpenShot/openshot-qt
    https://github.com/OpenShot/libopenshot
    https://github.com/cwilling/pvc

They all have in common the protocol and host parts of the url, namely https://github.com/. The projects are distinguished by the part of the url immediately following, namely OpenShot/openshot-qt, OpenShot/libopenshot and cwilling/pvc. The distinguishing parts of the url are used as the urlbase for these projects by PVC.

Some repositories host only a single project and therefore don’t need to be distinguished from others. In such cases the urlbase is actually superfluous, although it is still needed by PVC itself due to the way command arguments are currently processed.

The main task in implementing a module file for a new repository type is to provide a function check(parent, option) which, using information via the parent and options parameters, downloads whatever data is required from the repository, extracts version numbers from the data, then sorts them and provides the latest of them by emiting a signal whose type depends on the action with which the check() function was called (validate, check, or update). Most of this is boilerplate code available in a template, the most complex task being to extract the version numbers; even that is often completed in half a dozen lines of code (see vlc example below).

User generated module files Have a strict naming convention and must be installed in a particular directory in the user’s part of the file system, ~/.local/share/pvc. If that directory doesn’t yet exist it can be created manually (mkdir) or by running the pvc command itself, which creates the directory for its own use. The name of the module file must be:

    pvcWatcher-XXXX.js

where XXXX is a string of any length representing the new type which the module file supports. For example, a module file for a new boaconstrictor repository type would be named:

    pvcWatcher-boaconstrictor.js

More to come ….

Read this tutorial example for step by step details about creating a module file for PVC to support a new repository type.