handling identical pack names in different draft pack repositories

[michelleN]

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.

[alonisser]

My two cents:

1. There is always a default repo, if a language exists there it uses the repo
2. Pack specification on the CLI can override the repo used (when specifying a namespace_repo/pack)
3. repo adding command makes the added repo default (with flag not as default)
4. command to set another repo as default

Always can let the user choose dynamically on the cli from the options, but seems a little harder to implement

[squillace]

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.

[bacongobbler]

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 Azure/draft#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?

[squillace]

@michelleN @bacongobbler I like the proposed UX. My principles are these:

1. all collisions are the responsibility of the user and she should be alerted if there is a collision and given the information to resolve the problem.
2. We should bend over backward to help people quickly make a resolution choice.

your proposal feels great by both criteria.