src module

The "src" module allows packaging scripting language apps through self-referencing package infos.

• fpm issue: #811
• orig gist: fpm…package…src.rb

It's useful primarily for packaging source-language based applications (Python, etc). It looks for scripts decorated with per-file meta information in a top-level comment block (use # or // comments, or a /*...*/ block) such as:

# title: FooBar
# description: does the stuff
# version: 0.2
# architecture: all
# license: BSDL
# 
# Actual source comment starts here... 

src specifically utilizes an additional # pack: line, that can reference other files/script includes (recursively), which the fpm -s src module would uncover and pack along.

# pack: lib/dependency.py, ext/*.py, doc/README

Somewhat similar to the dir module it provides limited renaming support src.py=dest.py in its file references.

• It's probably still buggy mostly working (v0.7) with relative paths and upward ../ inclusions.

• Allows for simple file-to-file dependency chains / grouping.

• The glob-matching even supports some crude repositioning lib/*.sh=/opt/app/lib/shell/, but is one-level only.

• It alternatively permits using a plain spec.txt for packaging. fpm -s src -t deb spec.txt Where the pack: list in the spec file avoids listing any to-be-packaged files on the command line or .fpmrc.

• Notably it can augment fpm args --name, --description, --version, --maintainer, --license etc., when the inset script already documents those.

Use cases

For small projects a single pack: specifier in the main script/file often suffices. It just lists files to be included, general package descriptions, and which will be utilized with:

fpm -s src -t deb,rpm  main.sh

It's getting more interesting for modularized packages:

• Main source file st2.py

   # pack: st2.py=bin/streamtuner2,
   #       channels/__init__.py=share/streamtuner2/channels/
  

• And channels/__init__.py referencing the desired submodules

   # pack: a*.py, a*.png, m*.py, m*.png
  

From an actual example, which in reality isn't actually doing that. (Currently just packaging *.** everything there.)

Notes

The meta format is losely based on Generic PHP Plugins and also recognized by the versionnum copying tool. It's not formalized, but designed for cross-scripting language compatibility.

For FPM/XPM the inset script basename also becomes the package name in absence of an id: field.

The comment block after the meta fields will be used as --description field.