Open michelleN opened 6 years ago
My two cents:
Always can let the user choose dynamically on the cli from the options, but seems a little harder to implement
Question: can we not just use the github-namespaced repo url, as we have been? for example, --pack=github.com/squillace/draft-packs/packs/f-dotnetcore2-giraffe
? Sure, it's long, but as a specific URL, it's sufficient, I think.
Slight nuance here. This is when you've added two pack repositories to Draft, both with the same name (f-dotnetcore2-giraffe
) and you run draft create
with no --pack
flag.
handling the --pack
case is easy and it works as you described, but this particular issue is about how we handle that case for the default draft create
scenario. Do we:
1) assume one pack repo takes priority over another? (might be an awkward experience)
2) inform the user of the conflicting packs and to re-run draft create
with the --pack
flag?
I'm leaning in favour of option 2 with support to give the github-namespaced repo url via draft create
.
You can also imagine that perhaps a pack for python 2 and python 3 may conflict with one another since we're performing "language detection", which can't discern between code that was written for .NET 1.x or .NET 2.x (see https://github.com/Azure/draft/pull/346 for an example how I imagine this might work)
e.g. I propose this be the new system:
$ draft create
It looks like there are 3 packs that satisfy this application:
1) .NET 2.0 (from github.com/Azure/draft)
2) .NET 1.0 (from github.com/bacongobbler/draft-packs)
3) .NET 2.0 (from github.com/bacongobbler/draft-packs)
4) None of these satisfy this application
Choose one:
The user then enters a number, which then draft create
will bootstrap the application with the given pack.
For the --pack
case, users could run the following to get option 3:
draft create --pack-repo=github.com/bacongobbler/draft-packs --pack dotnet2
The reason why I think --pack-repo
would be OK to add to Draft: Pack Repositories are a core feature of Draft; draft pack-repo
is just a reference implementation on how to architect and fetch them using git.
How does that look for a UX standpoint?
@michelleN @bacongobbler I like the proposed UX. My principles are these:
your proposal feels great by both criteria.
If an application developer adds two repositories and both have a python pack, how do we differentiate between the two for
draft create
and otherwise.Helm handles this by namespacing charts with chart repositories.
chart-repo/chart
. For presentation, we could look into namespacing pack with the pack repository it lives in. That still leaves a question of how we handle collisions up in the air. Also still an open question: What pack and pack repo do we give preference and how they're weighted.