banksalad / python Goto Github PK

위 처럼 생성되는데 뱃지 간격이 너무 좁아 이쁘지 않음
본래 템플릿에 화이트 스페이스를 넣어봤으나 템플릿 생성시 화이트스페이스가 제거되어 생성되는 문제때문에 보류했었음.

As is

To be

• mypy.ini 추가
• .gitignore에 .mypy_cache/ 추가
• Makefile 업데이트
• pre-push 업데이트
• requirements-dev 업데이트

되는지 안되는지 리서치 필요 -> choice variables로 사용 가능 mypy - hard mode, mypy - easy mode

• hard 모드 / easy 모드: 모드에 따라 적용되는 옵션 단계가 다름
• hooks로 mypy 사용안할 시 mypy.ini 삭제하는 스크립트 추가

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번과 마찬가지로 공통으로 사용되는 파일에 대한 유지보수 어려움
  • ⭐️ 가 분산된다

코드오너로 @jungwinter @sunghyunzz @sean-ahn 추가를 제안합니다.

• 위치: .github/CODEOWNERS
• 내용: * @JungWinter @sunghyunzz @sean-ahn

기본으로 생성되는 README.md 파일의 기본적인 골격을 좀 더 잡아두어, 추가 문서 작업이 용이하도록 개선하면 좋을 것 같습니다. 그리고 힙-한 배지들도 기본으로 넣어두면 좋겠.. 😅

black을 사용할 때 double quote를 사용한다면 black에서 -S옵션(double quote인지 single quote인지 신경 안쓰겠다는 옵션, black은 기본적으로 double quote로 다 통일시켜버림)이 없어져도 됨

double quote: black -l 79 .
single quote: black -S -l 79 .

이 레포의 template을 어떻게 이용할 수 있는지 등 기본적인 가이드 내용이 문서로 추가되면 좋을 것 같습니다.

[mypy]
python_version = 3.7
ignore_missing_imports = Truecheck_untyped_defs = True
disallow_untyped_defs = True
disallow_any_generics = True
warn_no_return = True
no_implicit_optional = True

mypy expert 설정 시 줄바꿈이 되지 않습니다.

• .travis.yml with python version

• badge도 달 수 있으나 private repo같은 경우 token 값을 추가해줘야합니다.
  • e.g. ![Build Status](https://api.travis-ci.com/Rainist/private-repo.svg?token=travis-token&branch=develop) (이미지를 감싸는 링크는 생략했습니다)
  • token 없이 기본 뱃지를 달아두고 README 업데이트 때 갱신하면 어떨까 합니다 e.g. ![Build Status](https://travis-ci.com/Rainist/private-repo.svg)

• codecov도 travis가 yes라면 기본으로 포함시킬지? 아니면 choices로 제공할 수도 있구요. 얘도 token이 필요한데 위와 같이 생략하는 형태면 어떨까 합니다

@sunghyunzz

• pipenv를 사용할 때 pipenv install이 아닌 pipenv sync를 사용해야합니다.
  • 혹은 pipenv install -r requirements.txt 처럼 사용해야합니다.
  • pipenv sync를 사용하기 위해 Pipfile.lock도 프로젝트에 포함해야합니다.
• make requirements 추가
  • pipenv를 사용하는 메인테이너가 사용하지 않는 컨트리뷰터와의 협업을 위해 requirements.txt를 export할 수 있는 기능입니다.
• travis + codecov 연계 강화
  • make coverage에 xml 추가
  • .travis.yml의 after_success에 make coverage 하는 부분 추가
    • 그러지 않을 경우 codecov에서 커버리지 리포트를 인식하지 못함

• pipenv 사용 여부를 옵션으로 받게끔. 만약 사용한다면

• 기본적인 Pipfile 추가 -> pytest, pylint 등
• 마찬가지로 Pipfile.lock 추가 -> 굳이 추가해야하나 싶기도?

• cookiecutter 구현상 일단 추가해두고 post_gen_template.py에서 if 문으로 pipenv가 n 이면 rm으로 Pipfile, Pipfile.lock 삭제해야함

• .gitattributes 추가 -> git diff, git add 등에서 잡히지 않음. GitHub에선 잡힘
• Makefile에 pipenv run make format 등으로 변경
  • 이렇게 해야 travis 라던가 로컬에서 쓰기 편해지고 실수도 안발생함

• Dockerfile의 이미지를 Python 3.7.3으로 업데이트
  • 3.7.3 버전이 릴리즈 되었으므로 업데이트 해야합니다.
• black의 버전을 ==19.3b0으로 업데이트

이슈 및 PR 템플릿 생성

참고: github blog

• 3.7에서 추가된 라이브러리에 대해 스탠다드 라이브러리로 인식되도록 .editorconfig를 수정해야합니다.
• isort 에서 수정이 되었으나 릴리즈가 되어있지 않아 4.3.4 버전으로도 아직 미해결 상태입니다.

관련 이슈

• isort 깃헙 이슈
• isort 관련 PR

docker 를 사용할 수 없는 환경에서는 불필요해서
Dockerfile 생성을 선택할 수 있으면 좋을것 같네요

package/__main__.py을 실행시키는 간단한 Dockerfile을 추가하면 좋을 것 같습니다.

후킹한 설명이 있으면 좋겠습니다. 🕶

🍪 🐍 Rainist python project template using cookiecutter 같은?

Rainist의 다른 public repo의 관례를 보면 주로 MIT 라이센스를 사용하는 것 같은데 정확한 결정 후 LICENSE 파일을 추가해야합니다.