여러 use case 지원 방식 논의

[Jung Winter]

Flask를 사용할 때의 템플릿, Sanic을 사용할 때의 템플릿, 기타 등등의 템플릿 등 다양한 유즈 케이스에 맞는 프로젝트 기본 구조를 생성하려 할 때 이를 어떤 방식으로 구현 하는가에 대한 논의입니다.

생각해 봤을 때 크게 3가지가 있을 것 같은데 이 중에서 적절하다 생각되는 전략을 골라주셔도 좋고 다른 방법을 제안해 주셔도 좋습니다.

1. branch 전략

GitHub branch로 분리한 후 cookiecutter gh:rainist/python --checkout sanic 형태로 사용

• 장점: 사용할 때 간편하다.
• 단점: 유지보수의 어려움. master branch와 싱크를 매번 맞춰줘야 하는데 자칫 놓치면 outdated branch가 되기 쉽다.

2. post hook 전략 (개인적으로 선호하는 방식)

내부에 {{cookiecutter.package_name}}-sanic 등의 폴더로 구분 후 옵션을 입력받아 hooks/post_gen_project.py에서 선택된 패턴이 적용된 폴더의 이름을 {{cookiecutter.package_name}}로 수정 후 나머지 선택되지 않은 폴더를 삭제

• 장점: 한 레포에서 여러 패턴을 쉽게 유지보수할 수 있다.
  • 테스트로 각 유즈 케이스에 대해 테스트 가능
• 단점: use case 패턴마다 공통으로 공유하는 파일들이 적어 project root path에 여러 파일들이 널부러질 가능성이 존재한다.
  • 예를들어 sanic 패턴에선 pytest.ini를 사용하지만 flask 패턴에선 pytest.ini를 사용하지 않고 .coveragerc를 사용하는 등등

3. 마이크로 repository 전략

각 use case에 맞는 템플릿 레포를 그때그때 생성한다.

• 장점: 각 패턴에 맞게 깔끔하게 관리할 수 있다.
• 단점: Too much repo...
  • Rainist/python-sanic, Rainist/python-flask 너무 많아진다.
  • 1번과 마찬가지로 공통으로 사용되는 파일에 대한 유지보수 어려움
  • ⭐️ 가 분산된다

[Jung Winter]

@sunghyunzz @AhnSeongHyun @kanziw @sean-ahn 그동안 이 레포에 Issue & PR 을 날려주신 Contributor분들께 의견을 구합니다.

[Jiwoong Jung]

전 3. 마이크로 repository 전략 이 제일 좋다고 생각합니다.
단점으로 적어주신 것 중에는 공통으로 사용되는 파일에 대한 유지보수 어려움 부분이 제일 공감가긴 하지만 1. 공통 파일이 자주 바뀔 것 같지 않고 2. 각 레포마다 적용하는 것이 크게 귀찮은 작업은 아닐 것이라 생각합니다.

[안성현]

저도 3번 전략이 제일 나을것 같습니다. 1, 2번은 그 내부에서 지금은 sanic, flask 만 생각했을때는 유지보수가 괜찮을것 같지만, sanic, flask 내부에서 뭔가 더 세부사항이 생길경우, 3번 전략이 더 효과적일것 같습니다.

[Jung Winter]

cookiecutter README에 적혀있는 다른 템플릿들을 보면 3번 방향도 좋을거 같긴 합니다. 각 패턴에 맞는 템플릿을 더 깔끔하게 유지보수 할 수 있을 것 같은?

[황성현]

저도 3번 방향이 좋을 것 같습니다. 번거로움은 있겠지만 더 깔끔하게 운영이 가능할 것 같습니다.

[Jung Winter]

만약 다른 use case에 대한 템플릿 구현시 3번 방식대로 하겠습니다. 👨‍⚖