When making a complex seed packet, there are often a complex set of nested seeds. Some of them are entrypoints that should be exposed to a user, and some are just internal procedures that are factored out for convenience, but expect to be run in a context where certain variables are already set, for example, and will fail if they aren't.
Right now it's not possible to distinguish either of them.
Add a packet-level optional property, entrypoints:
{
"version": 0,
"entrypoints": {
"main" : "This is a main seed"
},
"seeds": {
"main": ...,
}
}
The keys of entrypoints must all be seed IDs in this packet. The value is a user-facing description of what the seed does and its usage. In the future there might be other properties attached to an entrypoint, at which point the value for each entrypoint can be a sub-object with keys, and the case of just being a string will be sugar for a config object of shape {"description": ${STRING}}.
If an entrypoint map is missing, it means that the entrypoints are implicitly all seeds, and the usage notes are the description property of each seed, or '' if none is provided.
The CLI should use this information to, for example, allow listing entrypoints in a seed packet and choosing one to run. (Although it still should be possible to list all seeds in a packet with a CLI option). See #1.
If an entrypoints map is provided, at packet load time we should validate that each seed is a known ID. See #39
Originally tracked in #36.
Another way to do this is to add more properties, like hidden or entrypoint:true to Seed definition, and handle this entirely automatically and with convention without top-level properties in the packet. For example, how often will you NOT want to include a top-level seed as a an entrypoint?
Yeah, maybe the approach is a SeedDataBase.hidden? : boolean field. Sub-seeds that are unrolled get a hidden:true unless they already have an explicit hidden:false. And you can provide a hidden:true to top-level seeds for implementation details you want to hide. And then the CLI just knows to not print hidden seeds unless -a is passed.
No, it should be private. A seed marked private will not show up in the CLI (unless -a is passed), and also may not be included from another seed packet (add a garden.publicSeed(ref) that will fail if the seed is private, and all sub-seed fetches use publicSeed
[ ] CLI shouldn't show private seeds unless -a is passed
When making a complex seed packet, there are often a complex set of nested seeds. Some of them are entrypoints that should be exposed to a user, and some are just internal procedures that are factored out for convenience, but expect to be run in a context where certain variables are already set, for example, and will fail if they aren't.
Right now it's not possible to distinguish either of them.
Add a packet-level optional property,
entrypoints:The keys of entrypoints must all be seed IDs in this packet. The value is a user-facing description of what the seed does and its usage. In the future there might be other properties attached to an entrypoint, at which point the value for each entrypoint can be a sub-object with keys, and the case of just being a string will be sugar for a config object of shape
{"description": ${STRING}}.If an entrypoint map is missing, it means that the entrypoints are implicitly all seeds, and the usage notes are the
descriptionproperty of each seed, or '' if none is provided.The CLI should use this information to, for example, allow listing entrypoints in a seed packet and choosing one to run. (Although it still should be possible to list all seeds in a packet with a CLI option). See #1.
If an entrypoints map is provided, at packet load time we should validate that each seed is a known ID. See #39
Originally tracked in #36.
Another way to do this is to add more properties, like
hiddenorentrypoint:trueto Seed definition, and handle this entirely automatically and with convention without top-level properties in the packet. For example, how often will you NOT want to include a top-level seed as a an entrypoint?Yeah, maybe the approach is a
SeedDataBase.hidden?: boolean field. Sub-seeds that are unrolled get ahidden:trueunless they already have an explicithidden:false. And you can provide ahidden:trueto top-level seeds for implementation details you want to hide. And then the CLI just knows to not print hidden seeds unless-ais passed.No, it should be
private. A seed marked private will not show up in the CLI (unless-ais passed), and also may not be included from another seed packet (add agarden.publicSeed(ref)that will fail if the seed is private, and all sub-seed fetches usepublicSeed-ais passed