https://etloveguitar.tistory.com/58

https://simpleisbetterthancomplex.com/packages/2016/10/08/isort.html

https://github.com/PyCQA/isort#readme

Git의 pre-commit 훅(hook)은 우리가 작성한 코드를 커밋할 때 마다 자동으로 특정 작업을 실행해줍니다.

많은 프로젝트들이 이를 통해 포멧터(formatter)를 실행하여 코드 스타일을 통일하고, 린터(linter)를 실행하여 코드에 잠재하고 있는 문제들을 찾아냅니다.

이번 포스팅에서는 Git의 pre-commit hook을 편리하게 사용할 수 있도록 도와주는 pre-commit라는 도구에 대해서 알아보겠습니다.

1. 설치

pre-commit은 자신의 컴퓨터에 파이썬이 설치가 되어 있다면 파이썬의 패키지 매니저인 pip를 사용하여 설치할 수 있습니다.

$ pip install pre-commit
Collecting pre-commit
  Downloading pre_commit-2.8.2-py2.py3-none-any.whl (184 kB)
     |████████████████████████████████| 184 kB 3.2 MB/s
Collecting toml
  Downloading toml-0.10.2-py2.py3-none-any.whl (16 kB)
Requirement already satisfied: pyyaml>=5.1 in /opt/virtualenvs/python3/lib/python3.8/site-packages (from pre-commit) (5.3.1)
Collecting cfgv>=2.0.0
  Downloading cfgv-3.2.0-py2.py3-none-any.whl (7.3 kB)
Collecting nodeenv>=0.11.1
  Downloading nodeenv-1.5.0-py2.py3-none-any.whl (21 kB)
Collecting virtualenv>=20.0.8
  Downloading virtualenv-20.1.0-py2.py3-none-any.whl (4.9 MB)
     |████████████████████████████████| 4.9 MB 4.6 MB/s
Collecting identify>=1.0.0
  Downloading identify-1.5.9-py2.py3-none-any.whl (97 kB)
     |████████████████████████████████| 97 kB 7.4 MB/s
Collecting distlib<1,>=0.3.1
  Downloading distlib-0.3.1-py2.py3-none-any.whl (335 kB)
     |████████████████████████████████| 335 kB 43.6 MB/s
Requirement already satisfied: six<2,>=1.9.0 in /opt/virtualenvs/python3/lib/python3.8/site-packages (from virtualenv>=20.0.8->pre-commit) (1.15.0)
Requirement already satisfied: appdirs<2,>=1.4.3 in /opt/virtualenvs/python3/lib/python3.8/site-packages (from virtualenv>=20.0.8->pre-commit) (1.4.4)
Collecting filelock<4,>=3.0.0
  Downloading filelock-3.0.12-py3-none-any.whl (7.6 kB)
Installing collected packages: toml, cfgv, nodeenv, distlib, filelock, virtualenv, identify, pre-commit
Successfully installed cfgv-3.2.0 distlib-0.3.1 filelock-3.0.12 identify-1.5.9 nodeenv-1.5.0 pre-commit-2.8.2 toml-0.10.2 virtualenv-20.1.0
WARNING: You are using pip version 20.1.1; however, version 20.2.4 is available.
You should consider upgrading via the '/opt/virtualenvs/python3/bin/python3 -m pip install --upgrade pip' command.

파이썬이 설치되어 있지 않다면, 운영체제의 패키지 매니저를 통해서도 설치할 수 있습니다.

예를 들어, MacOS 사용자는 Homebrew를 사용하면 됩니다.

$ brew install pre-commit

설치가 제대로 되었는지 확인해보기 위해서 버전을 출력해봅니다.

$ pre-commit -V
pre-commit 2.8.2

2. 설정

pre-commit은 .pre-commit-config.yaml이라는 설정 파일을 필요로 합니다.

터미널에 샘플 설정을 출력해주는 커맨드를 이용하여 설정 파일을 생성해보겠습니다.

$ pre-commit sample-config > .pre-commit-config.yaml

생성된 설정 파일을 열어보면, 4개의 훅(hook)이 설정되어 있는 것을 볼 수 있습니다.

# See https://pre-commit.com for more information
# See https://pre-commit.com/hooks.html for more hooks
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v3.2.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-added-large-files

pre-commit 도구는 인터넷에 공개되어 있는 Git 저장소로 부터 hook을 내려받아서 실행을 합니다.

즉, 우리는 실행하고 싶은 hook이 어느 Git 저장소에 위치하는지 알아야 합니다.

pre-commit 공식 홈페이지의 Supported hooks 페이지를 방문하시면 커뮤니티에서 제공하는 다양한 pre-commit hook을 만나볼 수 있습니다.

3. 실행

$ pre-commit run
[INFO] Initializing environment for https://github.com/pre-commit/pre-commit-hooks.
[INFO] Installing environment for https://github.com/pre-commit/pre-commit-hooks.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
Trim Trailing Whitespace.............................(no files to check)Skipped
Fix End of Files.....................................(no files to check)Skipped
Check Yaml...........................................(no files to check)Skipped
Check for added large files..........................(no files to check)Skipped

보통 초기 셋업 단계에서는 직접 pre-commit를 실행해보면서 설정이 잘 되었는지 확인이 필요합니다.

수동으로 pre-commit을 실행해주는 커맨드를 터미널에서 실행해보겠습니다.

설정 파일에 등록된 모든 hook이 설치된 후, 체크할 파일이 없어서 모든 hook의 실행이 생략되는 것을 볼 수 있습니다.

설정 파일을 스테이징 영역에 추가하고 다시 pre-commit 도구를 실행해보겠습니다.

$ git add .pre-commit-config.yaml
$ pre-commit run -a
Trim Trailing Whitespace.................................................Passed
Fix End of Files.........................................................Passed
Check Yaml...............................................................Passed
Check for added large files..............................................Passed

이번에는 모든 hook이 통과했다고 나오는 것을 확인할 수 있습니다.

$ git commit -m "creates .pre-commit-config.yaml"
[master (root-commit) d262bdb] creates .pre-commit-config.yaml
 1 file changed, 10 insertions(+)
 create mode 100644 .pre-commit-config.yaml

본격적인 테스트를 위해 설정 파일을 커밋하겠습니다.

4. 테스트

설정한 hook이 제대로 동작하는지 체크하기 위해서,

일부로 불필요한 공백(trailing whitespace)을 넣어서 test.txt 파일을 생성해보겠습니다.

$ echo "test " > test.txt

생성된 파일을 스테이징 영역에 추가하고,

pre-commit 도구를 실행해보면 trailing-whitespace hook이 실패한 것을 확인할 수 있습니다.

$ git add test.txt
$ pre-commit run
Trim Trailing Whitespace.................................................Failed
- hook id: trailing-whitespace
- exit code: 1
- files were modified by this hook

Fixing test.txt

Fix End of Files.........................................................Passed
Check Yaml...........................................(no files to check)Skipped
Check for added large files..............................................Passed

이렇게 hook이 실패한 파일은 자동으로 수정해 주기 때문에 변경분을 스테이징 영역에 추가 후,

다시 pre-commit를 실행하면 모든 hook이 통과하는 것을 볼 수 있습니다.

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   test.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   test.txt

$ git add test.txt
$ pre-commit run
Trim Trailing Whitespace.................................................Passed
Fix End of Files.........................................................Passed
Check Yaml...........................................(no files to check)Skipped
Check for added large files..............................................Passed

5. 자동화

pre-commit를 사용하는 최종 목적은 Git으로 커밋(commit)을 남길 때 마다 특정 작업을 자동으로 실행하는 것입니다. 이를 위해서는 프로젝트의 모든 개발자들이 Git 저장소를 클론받은 후에 제일 먼저 pre-commit install 커맨드를 실행해야 합니다.

$ pre-commit install

pre-commit installed at .git/hooks/pre-commit

이 명령어를 실행한 후에는 매번 pre-commit run 커맨드를 실행하지 않아도,

커밋을 할려고할 때 마다 자동으로 pre-commit이 실행이 됩니다.

$ echo "test " > test.txt
$ git add test.txt
$ git commit -m "adds test"
Trim Trailing Whitespace.................................................Failed
- hook id: trailing-whitespace
- exit code: 1
- files were modified by this hook

Fixing test.txt

Fix End of Files.........................................................Passed
Check Yaml...........................................(no files to check)Skipped

6. 마치면서

이상으로 pre-commit 도구를 어떻게 사용하는지에 대해서 간단히 살펴보았습니다.

pre-commit의 가장 큰 장점은 Git이 언어에 구애받지 않듯이, pre-commit도 언어와 상관없이 사용할 수 있다는 것입니다. 추후 기회가 되면 언어별로 자주 사용되는 hook에 대해서 다뤄보도록 하겟습니다.

출처

https://www.daleseo.com/pre-commit/

Django 프로젝트에서 파이썬 코드 스타일을 통일하기 위한 코드 정적 분석기인 flake8을 사용하는 방법에 대해서 알아봅시다.

1. 개요

Django로 서버사이드를 개발하면서 다른 개발자분들과 협업을 하게 되었습니다.

여러 개발자가 협업을 하므로, 코드의 스타일을 통일하고,

잠재적인 버그를 줄이기 위해, 코드 정적 분석기인 flake8을 도입하기로 했습니다.

이번 블로그 포스트에서는 Django 프로젝트에 flake8을 설정하고 사용하는 방법에 대해서 설명합니다.

• flake8: https://flake8.pycqa.org/

2. flake8 설치

Django에서 flake8을 사용하기 위해서는 우선, flake8을 설치할 필요가 있습니다.

다음 명령어를 사용하여 flake8을 설치합니다.

pip install flake8

설치를 하였다면, 잊지말고 requirements.txt에 저장해 둡니다.

pip freeze > requirements.txt

이것으로 flake8을 설치하는 방법에 대해서 알아보았습니다.

3. flake8 사용법

다음 명령어를 실행하여 flake8을 실행할 수 있습니다.

flake8

Django 프로젝트 폴더에서 flake8을 실행하면 다음과 같은 내용을 확인할 수 있습니다.

./venv/lib/python3.8/site-packages/pyflakes/checker.py:153:31: F821 undefined name 'PercentFormat'
./venv/lib/python3.8/site-packages/pyflakes/checker.py:160:9: F821 undefined name 'Generator'
./venv/lib/python3.8/site-packages/pyflakes/checker.py:160:9: F821 undefined name 'PercentFormat'
./venv/lib/python3.8/site-packages/pyflakes/checker.py:180:47: F821 undefined name 'Optional'
./venv/lib/python3.8/site-packages/pyflakes/checker.py:759:35: F821 undefined name 'List'
./venv/lib/python3.8/site-packages/pyflakes/checker.py:760:35: F821 undefined name 'Dict'

flake8의 결과를 보면 

checker.py:153:31: F821 undefined name 'PercentFormat'와 같이 

파일명:에러위치 에러ID 에러 내용을 확인할 수 있습니다.

4. flake8 설정하기

저는 djanog 프로젝트 폴더에 virtualenv를 생성하여 사용하고 있습니다.

그래서, flake8이 불필요하게 virtualenv 폴더까지 분석하고 있으니,

flake8이 virtualenv 폴더를 분석하지 않도록 설정할 필요가 있었습니다.

falke8이 virtualenv 폴더를 무시할 수 있도록 설정하기 위해,

flake8 파일을 Django 프로젝트 폴더에 생성하고 다음과 같이 수정하였습니다.

[flake8]
exclude =
    .git,
    .gitignore,
    *.pot,
    *.py[co],
    __pycache__,
    venv,
    .env

이렇게 설정하고, 설정이 잘 적용되었는지 확인하기 위해 아래에 명령어를 사용하여 flake8을 실행해 봅니다.

flake8

그럼 이전과는 다르게 다음과 같은 결과를 확인할 수 있습니다.

./petmeeting/settings.py:98:80: E501 line too long (91 > 79 characters)
./petmeeting/settings.py:101:80: E501 line too long (81 > 79 characters)
./petmeeting/settings.py:104:80: E501 line too long (82 > 79 characters)
./petmeeting/settings.py:107:80: E501 line too long (83 > 79 characters)
./petmeeting/settings.py:132:33: W292 no newline at end of file

flake8은 많은 내용을 체크하지만, 일반적으로 생각하지 않아도 되는 부분까지 에러로 표시하는 경우가 있습니다.

이런 부분들을 무시하기 위해서 저는 다음과 같이 무시할 내용들을 추가하였습니다.

[flake8]
exclude =
    .git,
    .gitignore,
    *.pot,
    *.py[co],
    __pycache__,
    venv,
    .env

ignore =
    E121,
    E126,
    E127,
    E128,
    E203,
    E225,
    E226,
    E231,
    E241,
    E251,
    E261,
    E265,
    E302,
    E303,
    E305,
    E402,
    E501,
    E741,
    W291,
    W292,
    W293,
    W391,
    W503,
    W504,
    F403,
    B007,
    B950,

max-line-length = 200

이 내용은 Sider라는 회사에서 추천하는 규칙을 적용한 내용입니다.

• sider_recommended_flake8

이 규칙은 단순히 정한건 아닌거 같고, 이 회사에서 연구한 결과를 바탕으로 추천하고 있는거 같습니다.

자세한 내용은 아래에 링크를 참고하시기 바랍니다.

• Recommended Ruleset

5. 완료

이것으로 Django 프로젝트에서 flake8을 사용하는 방법에 대해서 알아보았습니다.

또한 불필요한 규칙들과 폴더를 무시하기 위한 설정 방법에 대해서도 알아보았습니다.

앞으로 다른 개발자들과 협업하면서 이렇게 설정한 flake8이 많은 도움이 되기를 기대해 봅니다.

1. poetry 소개

poetry는 파이썬 의존성 관리 툴입니다.

단순하게 의존성 관리만 잘하는 툴이라면 추천할 이유가 별로 없을 것입니다. 

poetry는 단순하게 잘 한다 정도를 넘어서서 매우 잘 지원 해줍니다. 

poetry.lock을 사용해서 프로젝트의 의존성을 다른 환경에서도 동일하게 유지할 수 있고, 각 환경에서의 자동완성도 꽤나 잘 지원합니다.

또한, 기존 파이썬 패키지 관리 툴에서 볼 수 없었던, build와 publish까지 지원해주고 있어서,

실제로 프로젝트를 만들고 저장소에 배포까지 하고자 하는 사람에게는 굉장히 좋은 도구라고 생각됩니다.

깃헙의 python-poetry 라는 계정에서 관리되는데, poetry 하나를 위해서 따로 만든 프로젝트가 있을 정도로 꽤나 정성스럽게 만든 프로젝트입니다.

또한 사용법도 기존에 npm을 사용해 본적이 있다면 아주 친숙한 명령어들로 구성되어 있습니다.

단점이라면 새로 커맨드를 익혀야 하는 문제가 있으며, 기존의 프로젝트에 적용하기에는 약간 부담스러울 수 있다는 것입니다.

개인적으로는 새로만드는 프로젝트라면 주저없이 poetry를 써보라고 추천하고 싶습니다.

본 문서는 poetry의 설치 및 기본적인 사용법을 정리해서 조금이라도 많은 분이 좋은 프로젝트 환경을 구축하도록 돕기위한 글입니다. 시간이 지나면 본 문서의 내용과 달라질 수 있으므로 최대한 공식 사이트의 문서 를 참고하도록 합시다.

2. 설치

(1) 리눅스에서 설치 하기

curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python

(2) pip 로 설치

pip install --user poetry

설치를 하게되면 poetry 명령이 설치됩니다. 

poetry 명령어는 $HOME/.poetry/bin 에 저장되는데, PATH 환경 변수에도 추가가 됩니다.

추가가 되지 않았다면, .bash_profile 등의 파일에 PATH 의 환경변수에 추가해주세요.

패스에 추가하지 않고 바로 사용하려면 아래 명령어를 입력해주세요.

source $HOME/.poetry/env

(3) 탭완성(tab completion) 활성화하기

poetry 는 Bash, Fish, Zsh 에서 탭완성을 지원합니다. 

poetry help completions 명령어를 사용하면 각 쉘환경별 도움말을 확인할 수 있습니다.

귀찮으시면 아래 커맨드들을 확인하시면 됩니다.

# Bash
poetry completions bash > /etc/bash_completion.d/poetry.bash-completion

# Bash (Homebrew)
poetry completions bash > $(brew --prefix)/etc/bash_completion.d/poetry.bash-completion

# Fish
poetry completions fish > ~/.config/fish/completions/poetry.fish

# Fish (Homebrew)
poetry completions fish > (brew --prefix)/share/fish/vendor_completions.d/poetry.fish

# Zsh
poetry completions zsh > ~/.zfunc/_poetry

# Zsh (Homebrew)
poetry completions zsh > $(brew --prefix)/share/zsh/site-functions/_poetry

# Zsh (Oh-My-Zsh)
mkdir $ZSH/plugins/poetry
poetry completions zsh > $ZSH/plugins/poetry/_poetry

# Zsh (prezto)
poetry completions zsh > ~/.zprezto/modules/completion/external/src/_poetry

zsh 에서는 ~/.zshrc compinit 앞에 fpath+=~/.zfunc 을 추가해줍니다.

oh-my-zsh 에서는 ~/.zshrc 의 plugins에 poetry 를 추가해줘야 합니다.

plugins(
    poerty
    ...
)

3. 간단 사용법

(1) 프로젝트 셋업

poetry new my-project

위의 명령으로 프로젝트를 생성하면 아래와 같은 구조의 프로젝트가 생성됩니다.

my-project tree
.
├── README.rst
├── my_project
│   └── __init__.py
├── pyproject.toml
└── tests
    ├── __init__.py
    └── test_my_project.py

위에 보이는 pyproject.toml 파일이 바로 의존성을 관리하는 파일입니다. 열어보면 아래와 같이 생겼습니다.

[tool.poetry]
name = "my-project"
version = "0.1.0"
description = ""
authors = ["andy.sg"]

[tool.poetry.dependencies]
python = "^3.8"

[tool.poetry.dev-dependencies]
pytest = "^5.2"

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

의존성은 [tool.poetry.dependencies] 와 [tool.poetry.dev-dependencies] 에서 관리하고 있습니다.

의존성을 추가하고 싶다면 add 서브 커맨드를 사용하면 됩니다. 장고를 한번 추가해보도록 하겠습니다.

$ poetry add django

아래와 같이 출력이 나오게 됩니다.

Using version ^3.0.7 for django

Updating dependencies
Resolving dependencies... (7.1s)

Writing lock file


Package operations: 1 install, 9 updates, 0 removals

  - Updating pyparsing (2.4.6 -> 2.4.7)
  - Updating six (1.13.0 -> 1.15.0)
  - Installing asgiref (3.2.7)
  - Updating more-itertools (8.1.0 -> 8.3.0)
  - Updating packaging (20.1 -> 20.4)
  - Updating pytz (2019.3 -> 2020.1)
  - Updating sqlparse (0.3.0 -> 0.3.1)
  - Updating wcwidth (0.1.8 -> 0.2.3)
  - Updating django (2.2.9 -> 3.0.7)
  - Updating pytest (5.3.5 -> 5.4.3)

Writing lock file 에서 생성되는 파일이 바로 poetry.lock 파일인데, poetry.lock 파일이 있으면 내가 작성하고 있는 프로젝트의 의존성과 완전히 동일한 의존성을 가지도록 할 수 있습니다.

그러니 poetry.lock 파일을 꼭 저장소에 커밋 하도록 합시다.

pyproject.toml 을 보면 아래와 같이 django 의존성이 추가되어 있습니다.

[tool.poetry.dependencies]
python = "^3.8"
django = "^3.0.7"

(2) 버전 제약사항

django 의존성 설정을 보면 "^3.0.7" 이라고 되어 있습니다.

여기서 ^(캐럿) 의 의미는 ( >= 3.0.7, < 4.0.0) 의 의미입니다.

즉 3.9999....99999 버전까지도 설치가 된다는 얘기입니다.

의존성 스펙 문서를 보면 좀더 자세히 나와 있습니다.

4. 의존성을 최신으로 업데이트하기

아래의 커맨드를 입력하면 됩니다. $ poetry update

위 커맨드는 poetry.lock 파일을 삭제후 poetry install 하는 것과 동일합니다.

5. 패키징

poerty를 사용해서 tarball wheel 같은 배포가 가능한 파일로 빌드할 수 있습니다.

poerty build

위에서 만든 my-project 에서 실행하면 아래와 같이 나옵니다.

Building my-project (0.1.0)
 - Building sdist
 - Built my-project-0.1.0.tar.gz

 - Building wheel
 - Built my_project-0.1.0-py3-none-any.whl

실행후 dist 디렉토리에 가보면 아래와 같이 압축된 파일들이 있습니다.

my-project-0.1.0.tar.gz
my_project-0.1.0-py3-none-any.whl

6. 명령어들

(1) new

new 명령어로 새로운 프로젝트를 만들 수 있습니다.

poetry new my-site

위 명령어를 실행하면 아래와 같은 기본 디렉토리 구성을 만들어줍니다.

my-site
├── pyproject.toml
├── README.rst
├── src
│   └── my_site
│       └── __init__.py
└── tests
    ├── __init__.py
    └── test_my_site.py

(2) init

init 커맨드는 pyproject.toml 파일을 인터렉티브 하게 만들 수 있도록 도와줍니다.

poetry init

(3) install

install 커맨드는 현재 프로젝트의 pyproject.toml 파일을 읽어서 의존성 패키지를 설치해줍니다. poetry.lock 이 없으면 만들어주고 있으면 해당파일을 사용하게됩니다.

# 의존성 설치
poetry install

# 개발환경의 의존성은 빼고 설치
poetry install --no-dev

# -E 또는 --extras 로 추가 의존성을 설정가능
poetry install --extras "mysql redis"
poerty install -E mysql -E redis

(4) update

의존성 패키지의 버전을 업데이트하고 poetry.lock 파일을 업데이트 합니다.

# 패키지 업데이트
poerty update

# 하나씩 지정해서 업데이트도 가능
poetry update requests toml

# 업데이트는 하지 않고 poetry.lock 만 업데이트
poerty update --lock

(5) add

패키지설정을 pyproject.toml 에 추가합니다.

poetry add django

# 개발환경에서 필요한 패키지 설치
poetry add pytest factory-boy --dev

# 버전을 지정가능
poetry add django@^3.0.0
poetry add "django=3.0.0"

# 최신버전을 설치
poetry add django@latest

# 깃 저장소에 있는 패키지 설치
poetry add git+https://github.com/django/django.git

# 깃 저장소의 패키지에서 브랜치를 지정
poetry add git+https://github.com/django/django.git#stable/2.2.x

# 로컬에 디렉토리의 파일로 설치하기
poetry add ./my-package/
poetry add ./my-package/dist/my-package-0.1.0.tar.gz
poetry add ./my-package/dist/my-package-0.1.0.whl

(6) remove

패키지 삭제

poetry remove flask

# 개발환경 패키지 삭제
poetry remove pytest

(7) show

# 설치된 모든 패키지를 보여준다.
poetry show

# 개발환경용 제외하고 보여준다.
poetry show --no-dev

# 특정패키지를 지정하면 상세내용을 보여줍니다.
poetry show django

# 최신 버전을 보여준다.
poetry show --latest (-l)

# 업데이트를 해야하는 패키지들을 보여준다.
poetry show --outdate (-o)

# 의존성 트리를 보여준다.
poetry show --tree

(8) build

위에도 적었지만 소스를 배포가능한 형태로(tarball, wheel)빌드합니다.

poetry build

(9) publish

아래 명령어로 PyPI에 배포할 수 있습니다.

poerty publish

배포를 하려면 PyPI 계정이 필요합니다. 계정이 없다면 여기를 클릭 하시고 하나 만드셔도 좋습니다. 프로젝트명이 겹치면 배포를 할 수 없으니, 자신만의 독특한 프로젝트 명을 정해서 배포를 해보도록 합시다.

(10) config

config 커맨드로 poetry 관련 설정을 변경할 수 있습니다.

# 설정보기
poetry config --list


# 설정법
poetry config [options] [setting-key] [setting-value1] ... [setting-valueN]

(11) run

프로젝트의 virtualenv 에 커맨드를 전달하여 실행하게 됩니다.

poetry run python -V

(12) check

pyproject.toml 의 유효함을 체크하는 명령어입니다.

(13) search

패키지를 찾기위한 커맨드입니다.

예를들어 beautifulsoup 의 패키지명의 철자가 기억이 안나고 beautiful 만 기억나면 아래와 같이 할 수 있습니다 .

$ poetry search beautiful | grep soup

---------------------------------
# output
beautifulsoup (3.2.2)
beautifulsoup4 (4.9.1)

(14) lock

pyproject.toml 에 설정된 의존성들에 대한 lock 파일을 생성합니다. (설치X)

(15) export

export 명령어는 lock 파일을 사용해서 다른 의존성 포맷으로 변경할 수 있습니다.

poetry export -f requirements.txt > requirements.txt

7. 가상 환경 관리하기

poetry 로 가상환경(virtualenv)을 관리 할 수 있습니다.

일반적으로 아래와 같이 사용합니다.

$ poetry env use {파이썬경로}

만약에 python3 이 패스에 잡혀 있는 상황이라면 모든 경로를 적어주지 않아도 됩니다.

$ poetry env use python3

(1) 가상환경 정보보기

poetry env info 커맨드로 환경 정보를 확인할 수 있습니다.

저의 경우는 아래와 같이 출력되었습니다.

Virtualenv
Python:         3.8.1
Implementation: CPython
Path:           /Users/gyus/Library/Caches/pypoetry/virtualenvs/my-project-0CozYJQl-py3.8
Valid:          True

System
Platform: darwin
OS:       posix
Python:   /Users/gyus/.pyenv/versions/3.8.1

단순하게 가상환경의 path만 알고 싶은 경우라면 --path 옵션을 주면 됩니다.

$ poetry env info --path

(2) 가상환경 리스트 보기

만들어진 가상환경의 리스트는 아래의 명령어로 확인 가능합니다.

$ poetry env list

(3) 가상환경 삭제하기

삭제는 아래의 명령어로 가능합니다.

$ poetry env remove {python경로}

8. 마무리

파이썬은 nodejs, ruby 보다는 상대적으로 프로젝트 환경 관리가 용이하지 않다고 느낀적이 많이 있는데, 

poetry 는 기존에 사용하던 pyenv, virtualenv를 추가적인 연동 작업없이 자연스럽게 사용할 수 있게 해줍니다.

거기다 패키징과 배포를 쉽게 할 수 있도록 커맨드를 만들어 둔 점이 좋다고 생각합니다.

나온지 오래되지 않은 툴이기에 기존에 사용하던 프로젝트에 적용시에는 조심히 적용해야하겠지만,

새로만드는 프로젝트라면 과감히 적용해보는 것은 어떨까요?!

pipenv, pyenv, virutalenv 등등 많은 버전관리, 패키지 관리 툴들을 사용해보았지만,

파이썬에서 앞으로의 프로젝트 및 패키지 관리는 poetry 를 사용하는 사람들이 많아질 것 같습니다.

부족한 글이지만, poetry 사용에 도움이 되었으면 좋겠습니다.

출처

https://blog.gyus.me/2020/introduce-poetry/

Poetry 설치

공식 문서 참고 

1. 프로젝트 디렉터리 생성

mkdir goboard

2. Poetry 설정

(1) poetry 파일 생성 및 설정

touch pyproject.toml

[tool.poetry]
name = "goboard"
version = "0.1.0"
description = ""
authors = ["goboard kim<demo@demo.com>"]

[tool.poetry.dependencies]
python = "^3.9.1"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

(2) Django dependency 추가

poetry add django==3.1.3

3. django 프로젝트 생성

django-admin startproject config .

4. Django App 생성

django-admin startapp goboo

5. Django 프로젝트 결과

goboard
├── README.md
├── config
│   ├── __init__.py
│   ├── __pycache__
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── db.sqlite3
├── goboo
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   ├── models.py
│   ├── tests.py
│   └── views.py
├── manage.py
├── poetry.lock
└── pyproject.toml

장고는 파이썬 기반의 하이레벨 웹 프레임워크다. 꽤 오랫동안 사용되기도 했고.. 매우 안정적이기도 하고.. 한번 사용하면 개발속도가 엄청 빠르기도 하고.. 이미 나와있는 자료들도 많아서 배우기 쉬울 것이다.

이 글은 아래와 같은 사람들이 보면 좋을 것 같다!

1. 프론트 개발자인데 Firebase와 같은 DBaaS(DB as a Service) 플렛폼 사용할 때
2. 장고 개발자인데 최근에 React/Angular 또는 모바일 앱을 사용하려 할 때
3. 프론트엔드 시작하는 개발자인데 백엔드 개발에 어려움을 겪고 있을 때
4. 성숙한 프레임 워크를 사용하여 백엔드 서비스를 구축하고 싶을 때

1. 왜 Django를 Angular, React 또는 Mobile SDK와 함께 사용하는 것이 간단하지 않을까?

장고는 Full Stack 웹 프레임 워크로,

자체 ORM, 템플릿 엔진 등이 포함되어 있으며 전체 application이 단일 서비스로 실행되도록 제작되었다.

반면 프론트엔드 프레임워크 또는 모바일 SDK를 사용하는 경우

클라이언트/프론트 엔드가 백엔드에서 완전히 분리되도록 설계되어있다.

2. 그럼 굳이 왜 장고를 사용하려 하는거지?

프론트엔드와 백엔드간의 REST 기반의 통신 아키텍쳐로 완전한 Decoupling을 용이하게 할 수 있기 때문!

장고의 REST 프레임워크는 이전 포스팅에서 소개한 바가 있다.

그래서 제안된 아키텍쳐의 그림은 아래와 같다! 

Request를 HTTP 프로토콜로 하고 response는 JSON 형태로! Serializer와 API view가 필요하다.

3. 그래서 어떻게 모바일 백엔드를..?

백엔드 개발 순서가 따로 있는건 아니지만 추천을 한다면 먼저 모델을 개발하고(models.py), 그 다음에 seralizer.py, urls.py, views.py 순서로 하면 좋은 것 같다.

django-admin startapp (앱 이름) 명령어를 통해 앱을 생성하자. 모델은 원래 유저를 써보자.

메인 프로젝트 이름있는 폴더 안에서 seralizer.py를 생성하자.

(1) serializer.py 생성

#(앱이름)/serializer.py
 
from rest_framework import serializers
from django.contrib.auth.models import User
 
class UserSerializer(serializer.ModelSerializer):
	class Meta:
    	model = User
        fields = ('url', 'username', 'email')

원래 있던 유저의 정보를 serailize 하는 것이다!

필드는 직접 설정할 수도 있고, 모든 필드를 불러오고 싶다면 fields =  '__all__' 로 하면 된다.

(2) urls.py를 설정하자

#(프로젝트폴더이름)/urls.py
 
from django.urls import path
from user.views import fetch_user
 
urlpatterns = [
	...
    path('fetch_user/', fetch_user),
]

(3) views.py를 작성하자 (젤 중요!!)

#(앱이름)/views.py
 
from django.contrib.auth.models import User
from rest_framework.decorators import api_view
from .serializer import UserSerializer
from rest_framework.response import Response
 
@api_view(['get'])
def fetch_user(request):
	#fetch all user objects
    users = User.objects.all()
    serializer = UserSerializer(users, many=True)
    
    #return Response using rest_framework's response
    return Response(seralizer.data)

유저 정보를 받아오는 fetch_user 함수를 작성한 모습이다.

request가 들어오면 리턴하는 형식이다. 이 예시는 GET만 허용한다. (POST 안됨)

위의 serializer.py에서 만든 UesrSerializer를 통해 직렬화를 하고, many=True를 통해 잠재적으로 둘 이상의 객체가 있음을 알린다. api_view는 장고 rest 프레임 워크에서 제공하는 것으로, 이쁘게 보여주는 화면같은거다.

REST 프레임워크에서 Response를 import해와서 JSON 형식으로 응답하도록 했다.

응답은 serializer.data로 모든 유저 객체 정보를 보여주도록 설정했다.

(4) 실행시켜보자

python manage.py runserver 를 터미널에서 실행시키고 웹브라우저로 http://localhost:8000/fetch_user 를 들어가면!

이렇게 에러가 뜬다 ㅎㅎ views.py의 serializer 부분을 아래와 같이 수정하자.

serializer = UserSerializer(users, context = {'request' : request}, many = True)

그리고 다시 들어가보면 잘 된당

굳~~

이제 각자의 프론트엔드에서 개발을 할 때 http://localhost:8000/fetch_user 로 리퀘스트를 하면 백엔드와 정보를 주고받을 수 있다. 챱챱

출처

https://butter-shower.tistory.com/52?category=718374

https://www.django-rest-framework.org/tutorial/quickstart/

장고 REST 프레임워크 튜토리얼 문서를 따라하면서 익혀보도록 하자.

1. 프로젝트 만들기

새로운 장고 프로젝트를 만들고(rest_tutorial), 새로운 앱을 만들자. (quick start)

$ django-admin startproject tutorial
$ cd tutorial
$ django-admin startapp quickstart

그리고 django REST Framework를 설치하는 것도 잊지 말자.

$ pip install djangorestframework

이제 데이터베이스를 다시 처음으로 초기화하고 슈퍼 유저를 만들자

$ python manage.py migrate
$ python manage.py createsuperuser

2. Serializer 생성하기

먼저 serializer를 정의하자.

이 전에 포스팅에도 나와있는데, serialize를 한다는 것은 JSON이나 XML 파일 등으로 바꾸어 주는 것을 말한다.

tutorial/quickstart/serializers.py 를 생성해 아래의 코드 내용을 넣자.

#tutorial/quickstart/serializers.py
 
from django.contrib.auth.models import User, Group
from rest_framework import serializers
 
 
class UserSerializer(serializers.HyperlinkedModelSerializer):
    class Meta:
        model = User
        fields = ('url', 'username', 'email', 'groups')
 
 
class GroupSerializer(serializers.HyperlinkedModelSerializer):
    class Meta:
        model = Group
        fields = ('url', 'name')

하이퍼 링크를 하는 HyperlinkedModelSerializer를 사용했는데, 다른 것들도 다 사용할 수 있다.

근데 hyperlink를하는게 좋은 RESTful 디자인이라고 한다.

3. Views.py 작성

그 다음엔 뷰를 작성해보도록 하자.

# tutorial/quickstart/views.py
 
from django.contrib.auth.models import User, Group
from rest_framework import viewsets
from tutorial.quickstart.serializers import UserSerializer, GroupSerializer
 
 
class UserViewSet(viewsets.ModelViewSet):
    """
    API endpoint that allows users to be viewed or edited.
    """
    queryset = User.objects.all().order_by('-date_joined')
    serializer_class = UserSerializer
 
 
class GroupViewSet(viewsets.ModelViewSet):
    """
    API endpoint that allows groups to be viewed or edited.
    """
    queryset = Group.objects.all()
    serializer_class = GroupSerializer

ViewSet을 사용해서 편하게 작성할 수 있다.

(django rest framework가 제공해줌. 예쁘기도 하고 편하기도 하다.)

4. urls.py 작성하기

사실 혼자서 따라할때 여기가 자꾸 어디 urls.py인지 헷갈렸다.. tutorial/tutorial/urls.py 에 작성해야한다.

# tutorial/tutorial/urls.py
 
from django.contrib import admin
from django.urls import include, path
from rest_framework import routers
from quickstart import views 	#이 부분 수정함
 
router = routers.DefaultRouter()
router.register(r'users', views.UserViewSet)
router.register(r'groups', views.GroupViewSet)
 
# Wire up our API using automatic URL routing.
# Additionally, we include login URLs for the browsable API.
urlpatterns = [
    path('', include(router.urls)),
    path('api-auth/', include('rest_framework.urls', namespace='rest_framework')),
    path('admin/', admin.site.urls),
]

우리는 위에서 view 대신에 viewset을 사용해서 자동적으로 URLconf를 우리의 API에 생성할 수 있다.

그래서 그냥 라우터 클래스에 등록해주기만 하면 끝!

또, API URL들을 기본 제공하는 기능보다 더 추가하고싶다면 URL conf를 명시해주면 된다.

마지막으로, 로그인 로그아웃 디폴트를 추가해주었는데, 선택 사항이지만 매우 유용해서 추가했다. 굳~

5. settings.py 손보기

tutorial/tutorial/settings,.py 의 파일을 손보자. 아래의 코드 내용을 settings.py에 붙여넣어준다.

# in tutorial/tutorial/settings.py
 
REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
    'PAGE_SIZE': 10
}

그리고 INSTALLED_APPS 부분에도 'rest_framework'를 추가해준다.

# in tutorial/tutorial/settings.py
 
INSTALLED_APPS = [
	...
    'rest_framework',    # need to add
]

6. 실행

이제 수정한 파일들을 수정하도록 하자. 먼저 서버를 돌리자.

$ python manage.py runserver

웹 브라우저로 들어가보면 아래와 같은 결과가 나올 것이다.

출처

https://butter-shower.tistory.com/51?category=718374

MVC 패턴

디자인 패턴 중 하나로, Model, View, Controller의 약자이다.

디자인 패턴 :

어떤 특정한 것을 개발하는 중에 발생했던 문제점들을 정리해서 상황에 따라 간편하게 적용해서 쓸 수 있는 것을 정리하여 특정한 '규약'을 통해 쉽게 쓸 수 있는 형태로 만든 것을 말한다.

라이브러리나 프레임워크가 그에 따른 예. 결국 좀 더 쉽고 편리하게 사용할 수 있게 만든 특정한 방법을 뜻함.

MVC design pattern

하나의 어플리케이션, 프로젝트를 구성할 때 그 구성요소를 세 가지 역할(model, view, controller)로 구분한 패턴이다.

이 패턴을 사용하면 사용자 인터페이스로부터 비즈니스 로직을 분리하여 어플리케이션의 시각적인 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 어플리케이션을 만들 수 있다. 

• Model : 어플리케이션의 정보(데이터)를 나타냄
• View : 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타냄
• Controller : 데이터와 비즈니스 로직 사이의 상호 동작을 관리함.

1. 모델, Model

어떤 동작을 수행하는 코드를 말한다. 사용자에게 어떻게 보일지 신경 쓰지 않아도 되는 모델은 순수 public 함수로만 이루어진다. 몇몇 함수들은 사용자의 질의(query)에 대해 상태 정보를 제공하고 나머지 함수들은 상태를 수정한다.

모델은 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보해야한다. 이와 같은 통보를 통해 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가/제거/수정할 수 있다. 

2. 뷰, View

데이터 및 객체의 입력, 그리고 보여주는 출력을 담당함. 데이터를 기반으로 사용자들이 볼 수 있는 화면이다.

뷰는 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 읽어온다. 뷰는 모델이 가지고 있는 정보를 따로 저장해서는 안된다. 단지 읽어오기만 해야할 뿐! 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야 한다.

3. 컨트롤러, Controller

데이터와 사용자 인터페이스 요소들을 잇는 다리 역할을 한다. 즉, 사용자가 데이터를 출력하고 수정하는 것에 대한 '이벤트'들을 처리하는 부분을 뜻한다.

컨트롤러를 사용하여 모델의 상태를 바꾼다. 이 때 모델의 상태가 바뀌면 등록된 뷰에 자신의 상태가 바뀌었다는 것을 알리고 뷰는 거기에 맞게 사용자에게 모델의 상태를 보여준다.

왜 MVC 패턴을 사용해야 할까?

사용자가 보는 페이지, 데이터 처리 그리고 이 두가지를 중간에서 제어하는 컨트롤러 이 세 가지로 구성되는 하나의 어플리케이션을 만들면 각각 맡은 바에만 집중할 수 있게 된다. 서로 분리되어 각자의 역할에 집중할 수 있게끔 하여 개발을 하고 그렇게 어플리케이션을 만든다면 유지보수성, 확장성, 유연성 등이 증가하고 중복 코딩이라는 문제점 또한 사라진다.

RESTful이란

RESTful이란 Representational State Transfer의 줄임말이다.

먼저 REST에 대해서 소개를 하자면, http의 url과 http method(GET, POST, PUT, DELETE)를 사용해서 API 가독성을 높인 구조화된 시스템 아키텍쳐(framework)라고 생각하면 된다.

하나의 URL로 우리는 최소 4가지의 HTTP method를 전송할 수 있다.

스마트폰이 등장하기 전 IT 기업들은 웹 페이지를 보여주는 웹서버만 구현하면 됬다.

그 웹 서버에서 DB 서버의 데이터도 읽어오고 사용자들이 글을 남기면 DB 서버에 저장까지 하는 기능을 모두 담당했다. 하지만 스마트폰이 출시되고, 어플리케이션의 등장으로 더이상 웹으로만 서비스를 제공하는 것에는 한계가 있었다.

따라서 HTML로 렌더링 하는 웹서버가 아닌, JSON 혹은 XML 과 같은 형식을 통해서 데이터를 다루는 별도의 API 서버가 필요했다. 스마트폰 어플과 웹에서 동일한 기능을 제공하는데 기존의 웹서버를 계속 사용하면 매번 HTML을 읽어서 해당 태그에 있는 정보를 찾아내는 일은 정말 미친짓이기 때문이다. (덜덜)

따라서 RESTful 아키텍쳐를 HTTP Method와 함께 사용해 웹, 데스크탑 앱, 스마트폰 어플들까지 하나의 API 서버를 생성할 수 있다.

Django 또한 View 클래스 자체가 RESTful 한 서버를 만들기에 최적인 프레임워크다.

장고 REST 프레임워크는 웹 API를 구축하기 위한 강력하고 유연한 툴킷입니다.

DRF(Django Rest Framework)란

Django 안에서 RESTful API 서버를 쉽게 구축할 수 있도록 도와주는 오픈소스 라이브러리다.

Django REST framework를 사용하는 이유는 아래와 같다.

• 웹 브라우저 API는 범용성이 크다. 개발을 쉽게 만들어준다.
• 인증 정책에 OAuth1, OAuth2 를 위한 추가적인 패키지가 추가되어 있는 경우
• 시리얼라이즈 기능을 제공해준다. (DB data -> JSON)
• 문서화 및 커뮤니티 지원이 잘 되어있다.

Serializer 란

DRF의 가장 매력적인 기능으로는 Serializer가 있다.

Serializer란 말 그대로 직렬화하는 클래스로서, 사용자의 DB안에 사용자 프로필 사진, 이메일, 이름, 성별이 있다고 가정하면 사용자 모델 인스턴스를 JSON 형태 혹은 Dictionary 형태로 직렬화 할 수 있다.

예를 보면,

user = User(email="user@user.user", name="user", sex="Female", profile_image="user.png")
UserSerializer(user).data{
	"email" : "user@user.user",
    "name" : "user",
    "sex" : "female",
    "profile_image" : "user.png"
}

위와 같은 사용자가 있다면 DRF의 serializer를 통해 모델 인스턴스를 직렬화 할 수 있다.

실 사용시에는 만약 사용자 정보를 열람하는 URL이 /serializer/user/<user id>/가 있고 해당 View에는 user_id의 해당하는 모델 인스턴스의 정보를 리턴한다고 가정하자. 그렇게 되면 만약 우리가 /serializer/user/1/ 이라는 URL로 요청했을 시 user_id가 1인 사용자의 정보를 JSON 형태로 응답받을 수 있다.

이는 사용자 프로필 페이지에 접근했을 때 사용하는 View 라고 하면 사용자 페이지에 들어갈 때 마다 해당하는 사용자의 user_id만 URL에 입력해주게되면 각 사용자의 정보를 JSON 형태로 응답 받을 수 있을 것이다.

위와 같은 기능을 하는 Serializer를 ModelSerializer라고 부른다.

Django REST Framework 설치

pip install djangorestframework

위의 명령어를 터미널에서 실행시키자.

다음으로는 django settings.py 파일에서 INSTALL_APP 부분에 'rest_framework' 를 명시해주자.

INSTALL_APPS = [
	...
    'rest_framework', #add
]

참고한 블로그

https://yunhookim.tistory.com/7

https://butter-shower.tistory.com/50