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:
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.
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).
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):
- name = Foo
- version = 1.2.3-3
- depends = Bar ( > 3.4 ), Baz ( = 1.2 )
- build-depends = Language::Python
- arch = any
- runtime = any
- author = Someone
- type = STD Perl 6 Library
- dir = lib
- type = Python Library
- dir = pylib
- type = STD Perl 6 Script
- dir = bin
- type = Application data
- dir = data
- type = STD Perl 6 Tests
- dir = t
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.
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.
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.