Vue d'ensemble du manifest

mecapy.yml se place à la racine de votre dépôt et indique à MecaPy comment empaqueter, construire et exécuter votre code. C’est la source de vérité unique de la plateforme — tout le reste (versions de fonctions, ports de workflow, ressources) en découle.

Forme générale

Un manifest v1 comporte quatre blocs requis et un optionnel :

version: "1"            # figé à "1" — la version du format

package:                # identité, métadonnées, ressources par défaut
  name: bolt-sizing
  version: 0.1.0
  visibility: private
  resources:
    recommended: { cpu: 1, memory_mb: 512 }
    timeout: 60

runtime:                # comment le code s'exécute (mode A, B ou C)
  kind: python
  version: "3.12"

functions:              # les entrées exposées par la plateforme
  size:
    handler: bolts:size
    inputs:
      diameter: { type: Length }
      load:     { type: Force }
    outputs:
      stress:   { type: Stress }

quality:                # optionnel — contrôle par cas de test, etc.
  validation_testcases:
    on_deployment: true

Bloc	Requis	Rôle
version	oui	Version du format de manifest. Toujours "1".
package	oui	Nom, semver, visibilité, ressources par défaut, tags.
runtime	oui	Discriminant (kind: python | dockerfile | image) + champs par mode.
functions	oui	Une entrée par fonction exposée. Au moins une.
quality	non	Points d’ancrage de contrôle consommés au déploiement.

Ce que chaque bloc apporte

Package porte l’identité stable d’une version à l’autre — name + visibility + tags + author + license — plus les ressources par défaut héritées par chaque fonction tant qu’elle ne les surcharge pas. La version est en semver et s’incrémente à chaque déploiement qui change le code.

Runtime choisit l’un des trois modes d’exécution, qui renvoient au contrat de runtime :

• python (mode A) — image managée, construite par MecaPy depuis votre handler.
• dockerfile (mode B) — image construite par MecaPy depuis votre Dockerfile.
• image (mode C) — image récupérée telle quelle depuis un registry.

Le mode A lit la signature du handler ; les modes B/C sont agnostiques au langage et exigent des E/S typées explicites. Voir modes de runtime pour les champs de chaque mode.

Functions est un dict d’entrées nommées. Chacune déclare soit handler (mode A), soit entrypoint (modes B/C), plus des ports d’E/S typés et d’éventuelles surcharges de ressources par fonction. Plusieurs fonctions d’un même package partagent la même image — voir handlers pour les options.

Quality est un bloc de forme libre pour des points d’ancrage de déploiement transverses. Son seul consommateur actuel est validation_testcases.on_deployment : après le build d’une version, les cas de test référencés par le champ testcases: de chaque fonction sont exécutés, et selon fail_on_error un échec peut rendre la version non servable.

Où aller ensuite

Référence de syntaxe Chaque champ, chaque type, chaque valeur par défaut au même endroit.

Modes de runtime Choisir entre Python, Dockerfile et image pré-construite.

Handlers et entrypoints Ce qui va dans handler: (mode A) vs entrypoint: (modes B/C).

Ports d'E/S typés La déclaration inputs: / outputs: et le catalogue de types.

Exemples Des manifests réels et complets pour chaque mode.

Contrat de runtime Ce que le worker lit et écrit dans le conteneur.