Python open source 101

Python open source 101

파이썬 오픈소스 라이브러리를 만들며 느낀점들과 개발할 때 알고있으면 좋을 주제들에 대해 공유합니다. 라이브러리를 만들기 시작할 때 어떤 점을 염두에 두어야 할지, setup.py의 구성은 어떻게 해야할지, 패키지 매니저와 린트, 테스트, 커버리지, CI 구성을 통해 개발을 준비하는 법을 말하고 TDD의 장점, 파이썬 표준 라이브러리의 활용을 통해 어떻게 더 잘 개발할 수 있는지, 끝으로 개발 그 이후에 어떻게 관리해야하는지 버저닝, 문서화, 기여, 뱃지, 이슈해결에 대해서 말합니다.

22b02091761ba790122dd89436bce02c?s=128

Winter Jung

August 24, 2019
Tweet

Transcript

  1. 3.

    ੉ ߊ಴ח !3 라이브러리를 만드는 과정과 느꼈던 점 도움이 될만한

    정보 공유 제가 만든 라이브러리 쓰세요 구현상의 문제를 이렇게 해결했고 발표 소개
  2. 14.

    자동응답 API 형식 !14 01 동기 버튼 이름 or 유저

    입력 텍스트 or 미디어 파일 URL ⏩
  3. 17.

    모든건 POST /message !17 대부분의 봇 API가 그렇듯 앱이 알아서

    처리해야하는 문맥 다만 callback등이 없고 오로지 content 뿐 01 동기 ⏩
  4. 27.
  5. 29.

    3. 성가신 response 조합 !29 02 구상 3개 중 하나는

    필수 있을수도 없을수도 없으면 주관식 입력 ⏩
  6. 32.

    !32 02 구상 Pythonic하게 명확한 시나리오 플로우 간편한 시나리오, Depth

    추가 성가신 JSON response 조합 복잡한 if-elif-else 구조 어려운 시나리오 추가 ⏩
  7. 35.

    최종 컨셉 !35 02 구상 상태 전이시 실행할 함수 like

    view function chatter.route(request.json) 을 통해 트리거 ⏩
  8. 39.

    !39 02 구상 Response 객체 조합 State rule 기반 라우팅

    데코레이터를 통한 플로우 등록 Pythonic하게 명확한 시나리오 플로우 간편한 시나리오, Depth 추가 ⏩
  9. 40.

    02 구상 마지막으로 이름 정하기 !40 이미 누가 선점한 chatterbox

    → 패키지 이름은 chatterbox.py지만 import chatterbox 할 수 있게
  10. 42.

    !42 03 개발 01 setup.py 02 패키지 매니저 03 린트

    04 테스트 & 커버리지 05 CI 06 커밋 메시지 07 TDD 08 표준 라이브러리 09 릴리즈와 태그
  11. 52.

    Python 2 or 3 !52 Python 2를 지원할지 말지 Python

    3이라면 어느버전부터 지원할지 각 마이너버전마다 새로 생긴 기능 파악하기 03 개발 setup.py
  12. 55.

    Python 3.5 New syntax async/await a @ b *, **

    unpacking 동작 확장 (e.g. {'x': 1, **{'y': 2}}) New modules typing !55 03 개발 setup.py
  13. 56.

    Python 3.6 New syntax F 문자열 포매팅 f'Answer is {value}'

    변수 타입 힌팅 async 제네레이터 !56 03 개발 setup.py
  14. 58.

    Pipenv !58 03 개발 패키지매니저 • Pipfile, Pipfile.lock을 통한 의존성

    관리 • pipenv shell 로 가상환경 실행 (source venv/bin/activate) • 로 호환성유지 • pipenv install --dev 로 개발에만 필요한 패키지 따로 관리 • 중요한건 라이브러리 의존성 명시와 컨트리뷰터를 위한다는 것 pipenv lock -r > requirements.txt pipenv lock -dr > requirements-dev.txt
  15. 59.

    Pipenv !59 03 개발 패키지매니저 • Pipfile, Pipfile.lock을 통한 의존성

    관리 • pipenv shell 로 가상환경 실행 (source venv/bin/activate) • 로 호환성유지 • pipenv install --dev 로 개발에만 필요한 패키지 따로 관리 • 중요한건 라이브러리 의존성 명시와 컨트리뷰터를 위한다는 것 pipenv lock -r > requirements.txt pipenv lock -dr > requirements-dev.txt
  16. 60.

    Pipenv !60 03 개발 패키지매니저 • Pipfile, Pipfile.lock을 통한 의존성

    관리 • pipenv shell 로 가상환경 실행 (source venv/bin/activate) • 로 호환성유지 • pipenv install --dev 로 개발에만 필요한 패키지 따로 관리 • 중요한건 라이브러리 의존성 명시와 컨트리뷰터를 위한다는 것 pipenv lock -r > requirements.txt pipenv lock -dr > requirements-dev.txt
  17. 62.

    !62 03 개발 린트 PEP8 준수 pylint, flake8 등의 린터를

    통해 코드 품질 관리 isort, autopep8, yapf, black 등의 포매터를 통해
 일관된 코드 스타일 보장
  18. 66.

    03 개발 pytest unittest + nose < pytest 간결하고 깔끔한

    테스트 코드 읽기 쉬운 에러 리포트 fixture 플러그인 테스트
  19. 67.

    pytest unittest + nose < pytest 간결하고 깔끔한 테스트 코드

    읽기 쉬운 에러 리포트 fixture 플러그인 모든 unittest 코드는 pytest로 테스트 가능 03 개발 테스트
  20. 69.

    간결하고 깔끔한 테스트 코드 The cleaning hand of pytest 일일이

    기억해 사용해야 하는 assertXXX 패밀리 03 개발 테스트
  21. 70.

    간결하고 깔끔한 테스트 코드 The cleaning hand of pytest setUp,

    tearDown 를 사용하면 더 차이나는 코드 일일이 기억해 사용해야 하는 assertXXX 패밀리 네이티브 문법을 활용해 가독성 확보 03 개발 테스트
  22. 73.

    fixture와 플러그인 Pytest۽ Flask੄ DB పझ౟ ജ҃ ҳ୷ೞӝ Python pytest

    fixture Switching from nose to py.test at Mozilla 03 개발 테스트
  23. 74.

    tox & detox 03 개발 테스트 pyenv + tox로 다양한

    파이썬 버전에서 테스팅 detox로 병렬적으로 더 빠르게 tox.ini를 잘 만들어두면 CI도 거저먹기
  24. 75.

    tox & detox 03 개발 테스트 3.4 / 3.5 /

    3.6 버전에서 테스트 실행 가능
  25. 77.

    03 개발 커버리지 • codecov, coveralls: CI에서 리포트를 업로드, Integration

    활용 • PR이 커버리지를 어떻게 변화시키는지 알 수 있음
  26. 79.

    !79 03 개발 CI commit push 혹은 PR이 올라오면 travis의

    리눅스 환경, appveyor의 윈도우 환경에서 tox를 통해 다양한 파이썬 버전에서 pytest와 pylint를 돌리고 성공/실패를 알려주고 coverage를 codecov에 리포트
  27. 80.

    !80 03 개발 CI commit push 혹은 PR이 올라오면 travis의

    리눅스 환경, appveyor의 윈도우 환경에서 tox를 통해 다양한 파이썬 버전에서 pytest와 pylint를 돌리고 성공/실패를 알려주고 coverage를 codecov에 리포트
  28. 81.

    !81 03 개발 CI commit push 혹은 PR이 올라오면 travis의

    리눅스 환경, appveyor의 윈도우 환경에서 tox를 통해 다양한 파이썬 버전에서 pytest와 pylint를 돌리고 성공/실패를 알려주고 coverage를 codecov에 리포트
  29. 82.

    !82 03 개발 CI commit push 혹은 PR이 올라오면 travis의

    리눅스 환경, appveyor의 윈도우 환경에서 tox를 통해 다양한 파이썬 버전에서 pytest와 pylint를 돌리고 성공/실패를 알려주고 coverage를 codecov에 리포트
  30. 83.

    !83 03 개발 CI commit push 혹은 PR이 올라오면 travis의

    리눅스 환경, appveyor의 윈도우 환경에서 tox를 통해 다양한 파이썬 버전에서 pytest와 pylint를 돌리고 성공/실패를 알려주고 coverage를 codecov에 리포트
  31. 84.

    !84 03 개발 CI commit push 혹은 PR이 올라오면 travis의

    리눅스 환경, appveyor의 윈도우 환경에서 tox를 통해 다양한 파이썬 버전에서 pytest와 pylint를 돌리고 성공/실패를 알려주고 coverage를 codecov에 리포트 Integration
  32. 85.

    !85 03 개발 CI tests pylint source codecov tox travis

    & appveyor Python 3.4 Python 3.5 Python 3.6 pytest push GitHub
  33. 87.

    !87 03 개발 01 setup.py 02 패키지 매니저 03 린트

    04 테스트 & 커버리지 05 CI 06 커밋 메시지 07 TDD 08 표준 라이브러리 09 릴리즈와 태그 지금까지는 개발을 하기위한 환경이었다면
  34. 88.

    !88 03 개발 01 setup.py 02 패키지 매니저 03 린트

    04 테스트 & 커버리지 05 CI 06 커밋 메시지 07 TDD 08 표준 라이브러리 09 릴리즈와 태그 지금부터는 개발을 더 잘 하기위한 이야기
  35. 91.

    !91 03 개발 커밋 메시지 જ਷ ழ޿ ݫद૑ ੘ࢿߨ 1

    2 Ӓ۞ա જ਷ ழ޿ ݫद૑ח ࠄੋೠపب ب਑੉ ؽ
  36. 92.

    !92 03 개발 커밋 메시지 ⏩ chatterboxח Target: Description ഋध

    ࢎਊ Action: Things ഋध, Write what I do э਷ ഋधب оמ
  37. 94.

    !94 03 개발 TDD • 라이브러리를 개발하는데 가장 추천하고 싶은

    부분 • 테스트하지 않은 기능까지 완벽하게 돌아간다고 말할 순 없어도, 테 스트한 기능에 대한 걱정은 없어짐 • 세부 구현을 바꾸거나 최적화, 리팩토링 할 때도 걱정없이 • TDD가 만능은 아니다. 구현하다 기획이 바뀌고 후에 테스트를 고쳐 야 할 때도 • 처음 구상했던 Examples를 토대로 테스트를 먼저 구성하면 좋음
  38. 95.

    !95 03 개발 TDD • 라이브러리를 개발하는데 가장 추천하고 싶은

    부분 • 테스트하지 않은 기능까지 완벽하게 돌아간다고 말할 순 없어도, 테 스트한 기능에 대한 걱정은 없어짐 • 세부 구현을 바꾸거나 최적화, 리팩토링 할 때도 걱정없이 • TDD가 만능은 아니다. 구현하다 기획이 바뀌고 후에 테스트를 고쳐 야 할 때도 • 처음 구상했던 Examples를 토대로 테스트를 먼저 구성하면 좋음
  39. 96.

    !96 03 개발 TDD • 라이브러리를 개발하는데 가장 추천하고 싶은

    부분 • 테스트하지 않은 기능까지 완벽하게 돌아간다고 말할 순 없어도, 테 스트한 기능에 대한 걱정은 없어짐 • 세부 구현을 바꾸거나 최적화, 리팩토링 할 때도 걱정없이 • TDD가 만능은 아니다. 구현하다 기획이 바뀌고 후에 테스트를 고쳐 야 할 때도 • 처음 구상했던 Examples를 토대로 테스트를 먼저 구성하면 좋음
  40. 101.

    !101 03 개발 표준 라이브러리 • 라이브러리를 제작할 때 도움이

    되는 기본 라이브러리가 많이 있음 • functools: wraps, partial • itertools: 뭔가 lazy하게 처리하고 싶을 때, sequence 객체를 다룰 때 • contextlib: sqlite cursor를 다룰 때, contextmanager • collections: ChainMap, 3.4에서 dict unpacking이 필요할 때 • abc: ABCMeta, abstractmethod를 통해 인터페이스 제공 • pathlib: os.join, os.path가 필요없음
  41. 107.

    !107 03 개발 표준 라이브러리 ⏩ itertools & operator 2о૑

    keyboard 6о૑ message Text Photo Button Text Button X
  42. 117.

    !117 03 개발 릴리즈와 태그 • 0.1.0 버전 릴리즈 →

    git tag v0.1.0 • 버저닝에 관한 내용은 잠시 뒤에 • setup.py의 version과 GitHub의 태그를 동일하게 관리 • changelog 적기 편함
  43. 121.

    !121 03 개발 내 API는 간단한걸 쉽게 만들고 복잡한걸 가능케하며

    잘못된건 불가능하게 한다 API 체크리스트 라이브러리
  44. 122.

    !122 03 개발 API 체크리스트 • 간결함 - README 샘플

    코드, 보일러 플레이트 줄이기 • 일관성 - 네이밍 (단어 순서, 복수형), 통일된 빈 값 • 유연함 - 함수 분리, 추상화와 커스터마이징, Pythonic • 안정성 - 빠른 실패 • 각 항목에 대한 예제는 사이트에서 확인 가능
  45. 124.

    !124 04 관리 01 의미있는 버저닝 02 문서화 03 기여자를

    위해 04 뱃지달기 05 README 06 이슈해결 07 개밥먹기 08 홍보
  46. 125.

    !125 04 관리 의미있는 버저닝 • Semantic versioning (e.g. Python

    3.6.5) • 라이브러리를 다 만들어도 버그 수정, 기능 추가 등의 업데이트는 항 상 존재 • 메이저 버전, 마이너 버전, 패치 버전으로 의미있는 버저닝을 하자 • break change가 있으면 메이저 버전, 새로운 기능추가는 마이너 버전, 버그 해결은 해치 버전 업데이트 • 사람들에게 충분히 받아들여지고 성숙했다고 생각될 때 1.0.0
  47. 126.

    !126 04 관리 의미있는 버저닝 • Semantic versioning (e.g. Python

    3.6.5) • 라이브러리를 다 만들어도 버그 수정, 기능 추가 등의 업데이트는 항 상 존재 • 메이저 버전, 마이너 버전, 패치 버전으로 의미있는 버저닝을 하자 • break change가 있으면 메이저 버전, 새로운 기능추가는 마이너 버전, 버그 해결은 해치 버전 업데이트 • 사람들에게 충분히 받아들여지고 성숙했다고 생각될 때 1.0.0
  48. 127.

    !127 04 관리 의미있는 버저닝 • Semantic versioning (e.g. Python

    3.6.5) • 라이브러리를 다 만들어도 버그 수정, 기능 추가 등의 업데이트는 항 상 존재 • 메이저 버전, 마이너 버전, 패치 버전으로 의미있는 버저닝을 하자 • break change가 있으면 메이저 버전, 새로운 기능추가는 마이너 버전, 버그 해결은 해치 버전 업데이트 • 사람들에게 충분히 받아들여지고 성숙했다고 생각될 때 1.0.0
  49. 128.

    !128 04 관리 의미있는 버저닝 • Calendar Versioning (e.g. Pipenv

    2018.7.1) • Ubuntu, pytz, PyCharm, certifi 등 • 릴리즈 사이클이 주기적이거나 (pip), outdated에 민감한 프로젝 트거나 (pytz, certifi), 크거나 포괄적인 프로젝트(Ubuntu, Pipenv)라면 캘린더 버저닝을 고려
  50. 129.

    !129 04 관리 문서화 • 라이브러리를 사용할 개발자를 위한 문서화

    • 나는 내 코드를 다 알지만 다른 사람은 그렇지 않음 • 이 라이브러리는 어떻게 사용해야하고 → Getting started • 어떤 함수가 있고 파라미터로 어떤걸 받고 뭘 반환하고 → api reference • sphinx와 read the docs로 문서 유지 (sphinx 첫걸음, 시작하기)
  51. 130.

    !130 04 관리 문서화 • 라이브러리를 사용할 개발자를 위한 문서화

    • 나는 내 코드를 다 알지만 다른 사람은 그렇지 않음 • 이 라이브러리는 어떻게 사용해야하고 → Getting started • 어떤 함수가 있고 파라미터로 어떤걸 받고 뭘 반환하고 → API Reference • sphinx와 read the docs로 문서 유지 (sphinx 첫걸음, 시작하기)
  52. 131.

    !131 04 관리 문서화 • 라이브러리를 사용할 개발자를 위한 문서화

    • 나는 내 코드를 다 알지만 다른 사람은 그렇지 않음 • 이 라이브러리는 어떻게 사용해야하고 → Getting started • 어떤 함수가 있고 파라미터로 어떤걸 받고 뭘 반환하고 → API Reference • sphinx와 read the docs로 문서 유지 (sphinx 첫걸음, 시작하기)
  53. 133.

    !133 04 관리 기여자를 위해 CONTRIBUTING.md
 → 기여를 위해 알리는

    말. 테스트는 어떻게 할 수 있고 컨벤션은 이렇다
  54. 134.

    !134 04 관리 기여자를 위해 CONTRIBUTING.md
 → 기여를 위해 알리는

    말. 테스트는 어떻게 할 수 있고 컨벤션은 이렇다
  55. 135.

    !135 04 관리 기여자를 위해 ISSUE_TEMPLATE.md
 → 업데이트로 디렉토리 형식도

    지원
 버그 리포트에 필요한 정보를 담게끔 유도
  56. 136.

    !136 04 관리 기여자를 위해 ISSUE_TEMPLATE.md
 → 업데이트로 디렉토리 형식도

    지원
 버그 리포트에 필요한 정보를 담게끔 유도
  57. 137.

    !137 04 관리 기여자를 위해 ISSUE_TEMPLATE.md
 → 업데이트로 디렉토리 형식도

    지원
 버그 리포트에 필요한 정보를 담게끔 유도
  58. 138.

    !138 04 관리 기여자를 위해 • PULL_REQUEST_TEMPLATE.md → 어떤 변경이

    있는지, 체크리스트 로 빼먹은건 없는지 유도 • 프로젝트 최상위 위치에 .github 폴더를 만들어 관리 • 주석을 활용해 불필요한 설명이 노출되지 않도록
  59. 139.

    !139 04 관리 뱃지 달기 • CI: 빌드 상태 •

    라이센스 • pypi 기준 라이브러리 버전: stable, unstable • 지원되는 파이썬 버전 • 코드 커버리지: 이 라이브러리가 이만큼 건강하다 license license MIT MIT build build passing passing build build passing passing pypi pypi v0.2.4 v0.2.4 python python 3.4, 3.5, 3.6 3.4, 3.5, 3.6 codecov codecov 92% 92%
  60. 140.

    !140 04 관리 뱃지 달기 • CI: 빌드 상태 •

    라이센스 • pypi 기준 라이브러리 버전: stable, unstable • 지원되는 파이썬 버전 • 코드 커버리지: 이 라이브러리가 이만큼 건강하다 license license MIT MIT build build passing passing build build passing passing pypi pypi v0.2.4 v0.2.4 python python 3.4, 3.5, 3.6 3.4, 3.5, 3.6 codecov codecov 92% 92% https://badgen.net
  61. 141.

    !141 04 관리 리드미 • 프로젝트의 대문 • 보통 MD,

    RST: 이제 pypi에서 Markdown도 지원됨 • 라이브러리의 현재 상태 - 뱃지 • 무엇을 위한 라이브러리인지, 설치 방법, 간단한 사용 사례, 문서 링크, 기여 방법 • 자세한 사용방법은 read the docs로 분리시키기
  62. 142.

    !142 04 관리 이슈해결 • 이슈가 있다는건 관심을 갖고 사용해주시는

    분들이 있다는 의미 • 내가 발견하고 내가 수정할 버그더라도 이슈로 남겨두기 • 어떤 커밋을 통해 해결됐는지 명시 (커밋에 Close #4, Fix #3를 적어주면 자동으로 처리) • 이슈를 올려주는 분들도 고마운 컨트리뷰터분들이라는 생각으로
  63. 143.

    !143 04 관리 개밥먹기 • 돌고돌아 드디어 원래 목적이었던 내

    프로젝트에 내 라이브러리 사용하기 달성 • 해당 라이브러리로 개발된 프로젝트가 있다면 좀 더 신뢰할 수 있 고, 개발자 스스로도 지속적인 관심을 가질 수 있음 JungWinter/chef-hong JungWinter/chatterbox ⏩
  64. 145.

    !145 04 관리 홍보 • chatterbox.py는 카카오톡 봇 라이브러리다 보니

    국내 개발자가 타겟 • 페이스북 그룹, 개발자 사이트, 트위터 등 • 제작 경험을 공유하는 것 또한 좋은 홍보 방법 (저는 때를 놓쳤지만...) • 글로벌 타겟이라면 hackernews, reddit, medium 등도 좋은 홍보 수단 이게 마지막입니다
  65. 146.
  66. 147.

    !147 마치며 원래 목적을 달성했는가 → ✅ 나만 쓰려고 만들기와

    모두를 위해 만들기는 매우 달랐다 개발 자체보다 준비, 관리 등 다른 부분이 더 중요하다 문서화는 몰아서 하지말고 그때그때 해두자
  67. 148.

    !148 도움이 된 것들 - Go언어로 오픈소스 배송조회 서비스 만들기

    - Tox, Travis 그리고 Codecov 로 오픈소스 생태계에 기여하기 - 파이썬에서 편하게 테스트 케이스 작성하기: pytest, Travis CI, Docker - 정해진 데드라인
  68. 149.