Design considerations and todo

B0 file

• B0.ml file finding. Should we stop at the last B0.ml file upwards ? This would be nice if you operate in a vendored dir. But this also avoid problems like I do a checkout e.g. in a scratch directory in _b0 to build it. On the other hand we have --b0-file for these cases.
• Should a @@@B0.version be added ? Think harder about it an especially with respect to B0_kit.V000 versioning. and coherence with @@@B0.includes. Also we could require to specify say #require "b0.kit.v000". Write down a few properties we would like to have w.r.t. opam and/or inclusion and end-user support.
• Scope name for libraries the lib think may not be that good and rather confusing. Maybe devise a specific notation to access library definitions and allow dots in their name. ("/my.def.bla")

B0 library

Unit dynamic meta

For now we used 'a Fut B0_beta.key.

• See how it goes fares for sync. Push/pull.
• What about serializing them so that it can be read by `b0 unit get` ?

Unit actions

The current implementations raises a few questions. It will need to be refined, see B0_unit.action.

• action/cmdlet overlap
• Should we have the action as a meta key ?
• The action needs to be run or be aware of the deployement environment.
• Maybe we don't need to be given the build and simply let the unit's dynamic meta have whatever is needed.
• If we get a fast up-to-date check. How to we get the dynamic meta. (serialize ?).
• Should actions be definitions to apply on units ? Seems to get into testing territory.

b0 tool

• b0 build consider -x|-u ordering ?

Build API conventions

• Should ?meta be the initial or override an initial meta done by the combinator. initial ensures gets do not blow, but it could be nice to be able to override auto-derivations