Configuration Extension

As for all nmk projects config items, nmk-base ones are all overridable by other plug-ins and project files. But the ones described on this page are specifically designed to be extended.

Dependencies handling

The nmk-base plugin allows to declare and install different kind of dependencies in an nmk project.

System dependencies

The nmk-base plugin generates a loadme.sh script in the root folder of an nmk project (see the loadme task).

This shell script verifies if required system dependencies are installed. Depending on the current OS, if a dependency is not found :

  • on Linux (Debian-like distributions), the script will trigger the corresponding package install using apt install command.

  • on Windows, the script will display the URL from which this dependency can be manually installed and stop.

In order to add system dependencies to be verified by this script, the loadMeSysDeps config item can be extended by nmk projects or plugins. This item syntax is described below:

    loadMeSysDeps:
        COMMAND:
            apt: ["PACKAGE"]
            url: https://someurl.org/

With:

  • COMMAND being the dependency command that is expected on the system path (e.g. by checking which COMMAND command return)

  • apt being a list of Linux packages to be installed with apt install command

  • url being the URL of the download page for this system dependency

Python modules dependencies

The nmk-base plugin handles a Python virtual environment (”venv”) for nmk projects. It generates a requirements file (typically a requirements.txt file in the project root folder), and handles the venv lifecycle:

  • The loadme.sh script creates the venv if it doesn’t exist yet

  • The py.venv task maintains it up to date by adding new requirements when project files are updated.

nmk projects or plugins can extend the following config items to declare Python modules dependencies to be installed in the venv:

  • venvPkgDeps: list of Python modules names to be installed. Example:

    venvPkgDeps:
        - numpy
    
  • venvArchiveDeps: list of local Python module archives installed. Example:

    venvArchiveDeps:
        - /some/local/path/to/my-module.wheel
        - /some/other/module.tar.gz
    
  • venvFileDeps: list of requirements files to be merged in the generated requirements file. Example:

    venvFileDeps:
        - ${PROJECTDIR}/test-requirements.txt
    

Project information

nmk plugins or project can override to the following items to give information about the project:

  • projectName: string giving the name of the project Example:

    projectName: MyAwesomeProject
    
  • projectAuthor: string giving the author of the project Example:

    projectAuthor: The project team name
    

Plugin information

nmk plugins can contribute to the following items to give version/doc information:

  • nmkPluginsVersions: object giving the plugin version. Example:

    nmkPluginsVersions:
        my-plugin-name: 1.0.0
    
  • nmkPluginsDocs: object giving the URL to the plugin documentation. Example:

    nmkPluginsDocs:
        my-plugin-name: https://someurl/to/my/doc
    

Git ignored files

nmk projects or plugins that want to ignore some specific files/folders can contribute to the following items:

  • gitIgnoredFiles: list of files to be ignored by git. Example:

    gitIgnoredFiles:
        - some-generated-folder/
        - some-generated-files.*
    

Line endings handling

nmk projects or plugins that want to identify some file types for which the line endings must be kept can contribute to the following items:

  • linuxLineEndings: list of file extensions which must be kept with Linux line endings. Example:

    linuxLineEndings:
        - .csh
    
  • windowsLineEndings: list of file extensions which must be kept with Windows line endings. Example:

    windowsLineEndings:
        - .ps
    

Dirty check enablement

By default, the git.dirty task is disabled. nmk projects or plugins may override the gitEnableDirtyCheck item to implement a logic able to toggle this check in certain conditions (e.g. in automated builds).

Example:

gitEnableDirtyCheck:
    __resolver__: path.to.my.resolver