Azure / draft-classic

A tool for developers to create cloud-native applications on Kubernetes.
https://draft.sh
MIT License
3.92k stars 395 forks source link

Proposal: allow `draft create --pack` to accept a URL #704

Open bacongobbler opened 6 years ago

bacongobbler commented 6 years ago

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

  1. fork draft (at least until #698)
  2. edit packs/python to my liking
  3. draft pack-repo remove github.com/Azure/draft
  4. draft pack-repo add https://github.com/bacongobbler/draft
  5. 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:

  1. with #488: draft pack create draft-pack-python --from=python (much like heroku/heroku-buildpack-python)
  2. edit the pack to my liking, and publish it to Github at https://github.com/bacongobbler/draft-pack-python
  3. 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:

draft pack-repo create myorg-draft-packs --from=github.com/Azure/draft

And finally, we could also allow users to add these single-pack pack repositories if they like (contingent upon #509):

draft pack-repo add https://github.com/bacongobbler/draft-pack-python

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?