Target Systems for a Module

Perl 6 poses a new challenge on the distribution format for Modules. At first, because this modules may be written in a variable set of languages and they may use implementation-specific features that are not "STD Perl 6". That brings us the following two concepts:

Runtime

This defines which runtimes can run this module, it refers to all Perl 6 implementations (Pugs, Parrot, KP6, SMOP, v6-alpha). This may relate to the fact that this module uses a feature that is only present on this specific implementation. On the other hand, a module may define "runtime: any" to mean that the module uses strict STD Perl 6.

Architecture

This defines in which architectures this module can be built. This should refer to the arch triplet (i686-linux-gnu, i386-win32???, i386-linux-uclibc) and the build software must be able to realise about compatibilities. When a module is linux related but still independent of cpu and libc implementation, it can use any-linux-any. When a module is compatible with all architectures it may simply have "arch: any".

Source Package x Binary Package

In order to keep track of installed modules and files, it's important that the module should build a binary package before instalation. While the source package may have "runtime: any" and "arch: any", the resulting binary package will be specific to the runtime that compiled it, and eventually it will be specific to the host architecture (if the build process results in architecture-dependent files).

Versioning

One of the expected features of Perl 6 is the support of having different versions of the same module installed at the same time. This should be doable easily considering the existance of binary packages that will simply generate a different installation path that would include the versioning information. But on the other hand, sometimes a version is just a minor version that should always replace a previous version. That leads us to the major and minor versioning. A module version is then 0.0-1 where the number after "-" is the minor version.

Basic Source Package Layout

The source package is a .tar.gz file with mandatory README, copyright and META.yaml file, while the YAML file must have the following layout (dumb representation here):

module

name = Foo

version = 1.2.3-3

depends = Bar ( > 3.4 ), Baz ( = 1.2 )

build-depends = Language::Python

arch = any

runtime = any

author = Someone

source

parts

0

type = STD Perl 6 Library

dir = lib

1

type = Python Library

dir = pylib

2

type = STD Perl 6 Script

dir = bin

3

type = Application data

dir = data

Building

Each runtime implementation must support building the binary package from the generic source format using its own tools. For instance, parrot might need to build the bytecode for the modules, smop might need to compile some lowlevel C implementations for that module etc.

Dependencies

Types of relationship

depends: this module doesn't work without the other.

recommends: this modules is usually used with the other.

suggest: this module is better if used with the other.

conflict: this module can't be installed while the other is installed

replaces: this module conflicts with the other, and replaces it for depency resolution.

Scope of relationship

runtime: this means that the module must be installed when the binary package is installed.

pre-runtime: this means that the other module must be installed before this one.

build: this means that the other module must be installed in order for this module to be built

test: this means that the other module must be installed in order to test this module

That relates to each of the types, where

runtime depends is identified by the "depends" key

pre-runtime depends is identified by the "pre-depends" key

build depends is identified by the "build-depends" key

test despends is identified by the "test-depends" key

Where 'depends' may be replaced by all types of relationships.

Module Names

The names of the modules are the names that will be used to import the module. If the module will be called with some namespace prefix, like perl5:Foo or python:Bar, then the name of the module should include this prefix. Otherwise it's understood that the module will be available using that name independent of the language its implemented on. The responsability of the runtime to make sure that is sane during build. For instance, modules implemented in Python may be compiled and made available as if they were implemented in Perl.