USE CASES - `package create manuscript`

[ycexiao]

This is a collection of use cases for package create manuscript

• feat: allow users to choose template from a list in package create manuscript 's prompts #5

UC 1 - Simon wants to create a local manuscript repository

1. Simon needs to create a manuscript repository from a scikit-package template
2. Simon runs package create manuscript. In response to prompts, he gives a name for the repository and selects his desired template from the list
3. scikit-package-manuscript cookiecutter creates the manuscript directories on his local using his selected template

• feat: after running package create manuscript, create a GitHub repo and link the local one via GitHub API. #6

UC 2 - Simon wants to create a local manuscript repository and link it to a new GH repository

1. as UC1.1 - 1.3
2. spm creates a GitHub repository with the name given by Simon at the manuscript org or the username desired by Simon
3. spm links the local to the remote
4. spm pushes the template to the remote

Proposed solution

Use the GitHub API to create a remote repo and link the local manuscript.

[sbillinge]

@ycexiao these look to me like Use cases, so I think our standard title would be something like USE CASES: package create manuscript

[ycexiao]

@ycexiao these look to me like Use cases, so I think our standard title would be something like USE CASES: package create manuscript

Yes. I agree.

[ycexiao]

@sbillinge Are these use cases good enough to create issues for them?

For UC1: feat: allow user to choose template from a list in package create manuscript 's prompts
For UC2: feat: after running package create manuscript, create a GitHub repo and link the local one via GitHub API.

[sbillinge]

@sbillinge Are these use cases good enough to create issues for them?

For UC1: feat: allow user to choose template from a list in package create manuscript 's prompts For UC2: feat: after running package create manuscript, create a GitHub repo and link the local one via GitHub API.

Yes, I made a could of very small edits to the UCs, but as they now stand I think they are ready to go!

Just to bring you up to speed, I think UC1 is already handled by the cookiecutter that Yucong wrote, though we never got it working so it needs to be debugged. But the basic structure should be there.

UC2 just builds on UC1 by using GH API to create and link the remote GH repo, presumably by running commands in the post-gen, but I leave it to you to figure this out.

In principle there is a UC3 where this repo is then linked to an Overleaf, but this step is so trivial for me that I think it is not worth doing it.

@ycexiao I wonder if you could give some priority to at least UC1 (but also UC2) as I have a couple of these that I need to do and I am kind of waiting so I can test this out on some real cases!