The workflow becomes more or less the same from a pack repository standpoint, but it also creates new on-the-fly opportunities for users to extend and modify the standard set of packs to their liking.
This model of extending can also apply to pack repositories:
Now, as an ORG user of Draft, this enables some interesting workflows: smaller, more focused teams can fork the org's particular language pack repositories and apply their own logic based on their team's requirements, without needing to maintain the other packs in the repositories.
Open question: without a packs/ directory, how do we identify it's a pack? Do we just assume and trust that it's a pack? With #509 do we introduce a pack.toml with a pack's configuration at the root and check for that?
As a community user of Draft (important disctinction from a user outside of a larger organization),
If I wanted to extend the python pack in the default packs, right now I'd have to
draft pack-repo remove github.com/Azure/draft
draft pack-repo add https://github.com/bacongobbler/draft
draft create --pack=python
I must then maintain my fork of the community packs to stay in line with the other charts available through the community repo.
With this proposal, the process becomes:
draft pack create draft-pack-python --from=python
(much likeheroku/heroku-buildpack-python
)draft create --pack=https://github.com/bacongobbler/draft-pack-python
The workflow becomes more or less the same from a pack repository standpoint, but it also creates new on-the-fly opportunities for users to extend and modify the standard set of packs to their liking.
This model of extending can also apply to pack repositories:
And finally, we could also allow users to add these single-pack pack repositories if they like (contingent upon #509):
Now, as an ORG user of Draft, this enables some interesting workflows: smaller, more focused teams can fork the org's particular language pack repositories and apply their own logic based on their team's requirements, without needing to maintain the other packs in the repositories.
Open question: without a
packs/
directory, how do we identify it's a pack? Do we just assume and trust that it's a pack? With #509 do we introduce apack.toml
with a pack's configuration at the root and check for that?