vscode 환경의 장점은 수많은 플러그인을 통해 개발 생산성을 극도로 향상시킬 수 있다는 점입니다. 특히 각 언어 환경에서 제공되는 플러그인의 통합이 잘되는 편이라 단일 IDE 환경에서 다양한 플러그인의 혜택을 누릴 수 있습니다.
Python으로 코드를 만들면서 구문의 오류나 스타일 문제를 잡아내기 위해 널리 사용되는 플러그인이 pylint 입니다. vscode가 아닌 파이썬 환경에서 사용할 수 있는 linter 중 하나로 넓은 사용자층을 보유하고 있습니다.
그런데 이 플러그인이 vscode에서 궁합이 잘 맞지 않을 때가 있습니다. 기존에 개발 장비에서 없던 문제가 새 개발 장비에서 하나, 둘 계속 나오니 참 환장할 노릇입니다 ^^;; 오늘은 그 중에서 vscode 환경에서 pylint가 내뿜는 no-member 에러를 없애는 방법을 살펴보겠습니다.
pylint의 no-member 오류란?
pylint는 linter 도구로 코드를 분석하여 구문의 오류를 찾아내는 역할을 합니다. 구문의 오류 범주에는 사용자가 직접 만든 클래스나 함수도 당연히 포함됩니다. 제가 겪었던 문제는 Django 환경에서 클래스의 멤버 객체를 찾지 못하는 문제였습니다.
vscode는 pylint의 도움을 받아 아래와 같이 특정한 객체에 대하여 정의되지 않은 멤버를 호출하는 코드에 빨간 물결줄을 그려주면서 존재하지 않는 멤버라는 것을 알려줍니다. 문제는 존재하지 않는 멤버가 아니라는 것입니다 ^^;;
빌드는 잘되지만 에러라고 pylint가 자꾸 심기를 건드립니다.
이 문제가 더 당혹스러운 이유는 빌드에는 문제가 없기 때문입니다. 실제로 구문에 문제가 없지만 pylint가 제대로 사용자 정의 객체를 탐색하지 못하면서 발생하는 이슈라 보면 정확합니다. 빌드에 문제가 없지만 vscode IDE 상에서는 문제가 있는 구문인 것처럼 소스코드 파일을 열때마다 시뻘건 줄과 경고 문구를 쏟아내는데 스트레스가 꽤 큽니다.
해결방법 : vscode 공통 환경 설정에서 pylint 옵션 지정하기
이 문제를 해결하기 위해서는 vscode의 공통 환경 설정 settings.json 파일에서 pylint에 대한 옵션을 추가로 지정해 주어야 합니다. 기본적으로는 settings.json 파일에 pylint와 관련한 항목은 설정되어 있지 않습니다.
우리가 추가해야 할 내용은 아래와 같습니다. 이미지에는 오타가 있기 때문에 (--generated-members가 아니라 --generate-members입니다) 아래의 구문을 복사해서 settings.json 파일에 추가하는 것을 권장드립니다.
vscode를 사용하지 않는 환경에서는 pip를 이용해 pylint-django 플러그인을 설치하면 에러를 해결할 수 있다는 글도 검색하면서 봤던 것 같습니다. vscode가 아닌 환경에서 문제를 겪고 있다면 pylint-django 공식 가이드 문서에 따라 패키지 설치후 django 환경 변수를 지정해 보시기 바랍니다!
새로운 개발 장비가 생기면 이전에 사용하던 장비의 환경과 동일하게 준비하는 것이 은근 번거롭습니다. 한동안 손대지 않고 있던 파이썬 Python 장고 Django 프레임웍으로 개발된 코드를 새 장비에서 다루려다보니 역시나 의존성 문제들이 여러번 발생하고 있습니다.
그 중에서도 최초 환경 설치시에도 겪었던 mysqlclient 패키지 설치 이슈가 있어서 간략하게 정리해봅니다. 한줄 요약을 먼저하자면 Mac OS 환경에서는 homebrew 를 이용해 mysql 을 설치하는 것이 가장 쉽고 빠른 해결 방법입니다.
개발중인 과제는 requirements.txt 에 필요한 의존성 패키지들이 잘 정리되어 있습니다. virtualenv 를 사용할 수 있는 환경을 만들고 pip install -r requirements.txt 명령을 이용해 패키지를 잘 설치하던 와중에... 떡하니 mysqlclient 패키지 설치가 문제가 발생했습니다.
폴백 fallback 로직에 따라 하위 버전까지 내려가면서 설치 시도를 하느라 실제 터미널 화면에는 휘황찬란한 붉은색의 에러메세지가 도배되었습니다. 에러를 알려주려는 메세지는 여러줄이었지만 핵심을 찝어내면 mysql_config not found 에러가 문제였습니다. 구글링을 조금 해보면 Mac OS 에서는 mysql 설치로 해결하는 것이 정석인듯 합니다.
Collecting mysqlclient
Downloading mysqlclient-2.0.3.tar.gz (88 kB)
|████████████████████████████████| 88 kB 2.6 MB/s
ERROR: Command errored out with exit status 1:
...
...
Complete output (15 lines):
/bin/sh: mysql_config: command not found
/bin/sh: mariadb_config: command not found
/bin/sh: mysql_config: command not found
...
...
OSError: mysql_config not found
mysql_config --version
mariadb_config --version
mysql_config --libs
Homebrew 를 이용하여 mysql 을 설치하는 방법은 간단합니다. 사실 mysql 설치 외에도 다른 방법이 있을 거라 생각되지만 (로컬 환경에서 mysql 인스턴스를 띄울 일도 없어서...) 환경을 만들고 코드를 동작시키는 것이 더 급한 관계로 mysql 을 설치했습니다.
% brew install mysql
==> Downloading https://ghcr.io/v2/homebrew/core/protobuf/manifests/3.15.8
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/protobuf/blobs/sha256:a1615a95bf6f0bd3d9111fd0afa9260373295eadf147c35aef03e31abdbef6bc
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:a1615a95bf6f0bd3d9111fd0afa9260373295eadf147c35aef03e31abdbef6bc?se=2021-05-18T03%3A15%3A00Z&sig=fpdRcLV73XovJ%2BjHStE98SY%2B9UBYum6GJxr8QQa
######################################################################## 100.0%
...
...
MySQL is configured to only allow connections from localhost by default
To connect run:
mysql -uroot
To have launchd start mysql now and restart at login:
brew services start mysql
Or, if you don't want/need a background service you can just run:
mysql.server start
%
mysql 설치가 완료된 후 다시 pip 로 requirements.txt 에 기술된 항목들을 설치 시도해보니 특별히 문제 없이 mysqlclient 가 설치되는 것을 확인할 수 있었습니다. 똑똑한 pip 는 캐시에 저장된 mysqlclient 바이너리를 활용하여 패캐지 설치를 마쳤답니다 :-)
(업데이트) 트위터로 포스팅이 공유된 후 "왜 PyMySQL과 mysqlclient를 같이 쓰는가?"에 대한 이야기를 들었습니다. 그러고 보니... 왜 두개가 같이 들어가 있는지 생각도 못하고 있었네요. 다행(?)히도 같이 작업하시던 누군가 PyMySQL과 mysqlclient를 같이 시험하다 최종적으로 mysqlclient를 쓰기로 한 것이었습니다. requirements.txt에서 가볍게 삭제~
검색을 해보면 python에서 mysql 액세스를 하기 위해 널리 쓰이는게 PyMySQL과 mysqlclient, 그리고 peewee 정도인 것 같습니다. peewee는 ORM의 성격이 강한 것 같고 (써보진 않았습니다) mysqlclient는 C로 개발되어 속도가 빠르다, PyMySQL은 python 으로 만들어졌다 정도의 특징들이 있는 것 같네요!
어제는 간만에 Flutter로 코드 만들어 보느라 고생했고 오늘은 또 간만에 파이썬으로 코드 만드느라 고생중입니다. 그 사이에 무슨 일이 있었던 것인가... (빅써 없데이트!?) 갑작스레 새 코드 프로젝트를 만들기 위해 virtualenv 를 돌리는데 Library not loaded 에러가 발생합니다. 자연스레 pip 로 virtualenv 를 업데이트 해볼랬더니.. 어라? pip도 동작을 안합니다.
% virtualenv
dyld: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Referenced from: /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Reason: image not found
zsh: abort virtualenv
% pip
dyld: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Referenced from: /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Reason: image not found
zsh: abort pip
뭔가 운영체제 업데이트가 되면서 symlink가 꼬인 느낌이라 과감히 brew 로 파이썬을 재설치 해보기로 했습니다. 의존성이 걸려있는 패키지가 너무 많은 탓인지 업데이트가 한참 걸리네요. 열심히 다운로드 받고 설치하는 동안 저의 맥북프로는 또 다시 이륙을 하고는 고도를 높여 나갑니다...
% brew install python
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 3 taps (homebrew/core, homebrew/cask and homebrew/services).
...
...
==> Installing python@3.9
==> Pouring python@3.9-3.9.2_1.big_sur.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/2to3
Target /usr/local/bin/2to3
already exists. You may want to remove it:
rm '/usr/local/bin/2to3'
To force the link and overwrite all conflicting files:
brew link --overwrite python@3.9
To list all files that would be deleted:
brew link --overwrite --dry-run python@3.9
Possible conflicting files are:
/usr/local/bin/2to3 -> /Library/Frameworks/Python.framework/Versions/3.6/bin/2to3
/usr/local/bin/easy_install-3.9 -> /usr/local/Cellar/python@3.9/3.9.0_2/bin/easy_install-3.9
/usr/local/bin/idle3 -> /Library/Frameworks/Python.framework/Versions/3.6/bin/idle3
/usr/local/bin/pip3 -> /usr/local/Cellar/python@3.9/3.9.0_2/bin/pip3
/usr/local/bin/pip3.9 -> /usr/local/Cellar/python@3.9/3.9.0_2/bin/pip3.9
/usr/local/bin/pydoc3 -> /Library/Frameworks/Python.framework/Versions/3.6/bin/pydoc3
/usr/local/bin/python3 -> /Library/Frameworks/Python.framework/Versions/3.6/bin/python3
/usr/local/bin/python3-config -> /Library/Frameworks/Python.framework/Versions/3.6/bin/python3-config
==> /usr/local/Cellar/python@3.9/3.9.2_1/bin/python3 -m ensurepip
==> /usr/local/Cellar/python@3.9/3.9.2_1/bin/pip3 install -v --global-option=--no-user-cfg --install-option=--force --install-option=--single-version-externally-managed --install-option=--record=installed.txt --upgrade --target=/usr/local
==> /usr/local/Cellar/python@3.9/3.9.2_1/bin/pip3 wheel --wheel-dir=/usr/local/Cellar/python@3.9/3.9.2_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ensurepip/_bundled /usr/local/Cellar/python@3.9/3.9.2_1/libexec/setuptools /us
==> Caveats
Python has been installed as
/usr/local/bin/python3
Unversioned symlinks `python`, `python-config`, `pip` etc. pointing to
`python3`, `python3-config`, `pip3` etc., respectively, have been installed into
/usr/local/opt/python@3.9/libexec/bin
You can install Python packages with
pip3 install <package>
They will install into the site-package directory
/usr/local/lib/python3.9/site-packages
See: https://docs.brew.sh/Homebrew-and-Python
...
...
brew 의 로그를 보면서 에러가 난 부분들을 집중적으로 살펴봅니다. 확실히 python 3.9 를 설치하는 과정에 link 연결이 원활하지 않은게 보이는군요. 설치가 끝나는대로 brew link 명령을 --overwrite 으로 돌려보는게 좋을 것 같습니다. 그나저나 설치는 언제 끝나나...하고 있는데 설치가 끝났네요. 자 한번 brew link 를 수행해 보겠습니다
% brew link --overwrite --dry-run python@3.9
Would remove:
/usr/local/bin/2to3 -> /Library/Frameworks/Python.framework/Versions/3.6/bin/2to3
/usr/local/bin/idle3 -> /Library/Frameworks/Python.framework/Versions/3.6/bin/idle3
/usr/local/bin/pydoc3 -> /Library/Frameworks/Python.framework/Versions/3.6/bin/pydoc3
/usr/local/bin/python3 -> /Library/Frameworks/Python.framework/Versions/3.6/bin/python3
/usr/local/bin/python3-config -> /Library/Frameworks/Python.framework/Versions/3.6/bin/python3-config
%
% brew link --overwrite python@3.9
Linking /usr/local/Cellar/python@3.9/3.9.2_1... 21 symlinks created.
%
%
% python3
dyld: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Referenced from: /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Reason: image not found
zsh: abort python3
하아... 뭔가 잘 해결이 안되었네요. 분명 3.9 를 설치한 것 같은데 에러 내용의 중간을 보니 3.6을 참조하고 있는게 문제인 듯 싶습니다. python3 의 위치를 탐색해서 강제로 symlink 를 변경해 보도록 하겠습니다.
% which python3
/Library/Frameworks/Python.framework/Versions/3.6/bin/python3
%
%
% cd /Library/Frameworks/Python.framework/Versions/3.6/bin/
% rm python3
%
% which python3
/usr/local/bin/python3
하하~! 요렇게 하니 이제 새로 설치된 python3.9 버전이 잘 실행이 됩니다. 그러나 여전히 virtualenv나 pip가 제대로 동작하지 않았습니다.
% python3
Python 3.9.2 (default, Feb 24 2021, 13:26:09)
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
뭐가 문제일까 하다가... 문득 .bash_profile 에 추가되었던 PATH 정보가 생각나서 이 부분을 모두 제거하고 터미널을 재기동 해보았습니다. 그리고 나니 이제야 제대로 동작하는 virtualenv 와 pip..!! 개발 환경은 처음 설정이 늘 어렵고 번거롭고... 그런것 같습니다 ㅎㅎ. 비슷한 어려움을 겪는 분들이 계시다면,
1. brew 로 python 패키지 업데이트 2. symlink 가 이상하게 걸려 있는지 확인 3. PATH 로 잡혀 있는 파이썬 디렉토리 확인
이제 본격적으로 프로젝트의 내용물을 채워보도록 하겠습니다. 별도의 외부 데이터베이스를 사용하지 않고 기본적으로 제공되는 파일 기반의 데이터베이스인 Sqlite 를 그대로 사용하도록 하겠습니다. 데이터베이스를 쓰기 위해서 먼저 기본 테이블을 생성해야 하는데요, Django 는 데이터베이스를 이용하는 것을 전제로 사용자와 사용자 권한 그룹 테이블을 알아서 만들어 주도록 되어있습니다.
기본 테이블의 생성
기본 테이블을 생성하거나 프로젝트에 필요한 테이블을 생성하는 것 모두 manage.py 가 제공하는 명령어를 이용할 수 있습니다. 기본 테이블의 구조는 미리 정의가 되어 있기 때문에 모델을 만드는 작업을 하지 않고 사용이 가능합니다. 프로젝트의 루트 경로에서 manage.py migrate 명령을 사용하여 기본 테이블인 admin, auth, contenttypes, sessions 의 4개 테이블을 생성할 수 있습니다.
% python3 manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying auth.0010_alter_group_name_max_length... OK
Applying auth.0011_update_proxy_permissions... OK
Applying sessions.0001_initial... OK
migrate 명령이 수행되고 나면 settings.py 에 지정된 기본 데이터베이스 정보에 따라 Sqlite 용 파일이 프로젝트 루트 경로에 생성된 것을 보실 수 있습니다. 추후 Django 에 익숙해져 외부 데이터베이스를 사용하는 경우에는, 해당 데이터베이스 인스턴스에 4가지 테이블이 생성된다고 보시면 되겠습니다.
프로젝트용 테이블의 생성
기본 테이블은 Django 를 이용한 과제의 공통 테이블의 성격입니다. 수퍼 유저의 정보와 같은 것들이 이곳에 저장되는 것이지요. 실제 프로젝트에서 사용할 테이블을 정의하고 생성해야 하겠죠? 지난 포스팅 이후 뭘 만들어 볼까 고민하다가... 인터넷 서핑을 하면서 마음에 드는 이미지를 모아두는 서비스를 만들어 보면 어떨까 생각을 해보았습니다. (그닥 재미있어 보이진 않는군요...)
이미지의 이름 (Title) 과 이미지의 경로 (URL) 이고, 추후 검색 기능등을 넣기 위해 태그 (Tags) 정보를 입력받아 저장해보겠습니다. 지난 시간에 추가한 어플리케이션인 myfirstapp 폴더에 생성된 여러 파일들 중 models.py 를 열겠습니다. 이 파일에는 어플리케이션이 사용할 데이터, 테이블의 구조가 기술되며 이를 기반으로 manage.py 가 데이터베이스에 테이블 생성 작업을 대행해주기도 합니다.
물론 별도로 데이터베이스를 수정하고 내용을 models.py 에 반영하는 것도 가능하지만 models.py 를 먼저 수정하고 manage.py 를 이용해서 데이터베이스 작업을 하는 것이 초보자에게는 좋다고 생각합니다. 사실 회사에서 과제를 진행하면서 migrate 과정에 대한 의문이 좀 많았는데 원격지의 리얼 데이터베이스를 쓰는 경우에는 migrate 을 잘 활용하는 것이 DBA 의 눈도 피할 수 있어서 좋을 것 같군? 하는 생각도 좀 들긴 합니다.
이번 포스팅에서는 테이블 구조를 기술할 때 사용하는 django.db.models.Model 클래스를 자세히 살펴보지는 않겠습니다. 아직 공부를 못한 것도 있고 (퍽퍽...) 일단은 과제 하나를 잘 수행해 보는 것이 좋다고 생각하기 때문입니다 (후훗). 눈으로 보더라도 최대 길이라던가 빈 값의 허용, null 도 허용할 것인가와 같은 우리가 데이터베이스에서 테이블을 만들때 입력하는 정보들이 대부분 기술된다고 보시면 되겠습니다.
Admin 사이트에 생성한 테이블 반영
admin.py 를 수정하면 생성한 테이블 정보를 django 가 제공하는 기본 어드민 페이지 (0.0.0.0:8000/admin) 에서 관리하거나 간단한 데이터 입출력 작업을 할 수 있게 됩니다. 지난 포스팅에서 이야기 했는지 기억이 잘 안납니다만 php 에서 쓰는 phpmyadmin 과 같은 역할이라고 생각하시면 편합니다. 우리가 생성한 어플리케이션인 myfirstapp 폴더 하위의 admin.py 를 열어서 아래와 같이 수정해 보겠습니다.
테이블을 Sqlite 데이터베이스에 반영하려면 manage.py 가 제공하는 makemigrations 와 migrate 명령을 사용하게 됩니다. makemigrations 는 migrate 명령이 이해할 수 있도록 models.py 에 기술된 내용을 확인하고 현재의 데이터베이스와 비교하여 변경이 필요한 부분을 추출, python 코드로 만드는 역할을 수행합니다. migrate 은 이렇게 정리된 내용을 실제로 데이터베이스에 반영하는 역할을 하는 것이겠죠?
명령을 수행하기전에 어플리케이션 폴더인 myfirstapp 하위의 migrations 폴더를 살펴보면 __init__.py 파일만 존재하고 아무런 내용이 없는 것을 확인할 수 있습니다. makemigrations 명령을 수행한 후에 해당 폴더의 내용들이 어떻게 바뀌는지 살펴보도록 하겠습니다.
명령을 수행하고 나면 myfirstapp/migrations 폴더에 0001_initial.py 라는 파일이 생성된 것을 볼 수 있습니다. 느낌은 첫번째 마이그레이션 작업이라는 느낌이죠? 이 파일을 열고 내용을 살펴보면 데이터베이스 작업에 필요한 파일로 조금전에 models.py 에 업데이트 했던 내용들이 들어가 있는 것을 확인할 수 있습니다.
% python3 manage.py makemigrations
Migrations for 'myfirstapp':
myfirstapp/migrations/0001_initial.py
- Create model ImageCollector
이제 manage.py 의 migrate 명령으로 생성된 마이그레이션 작업 파일을 수행하여 데이터베이스에 반영되도록 하겠습니다. 기본 테이블로 생성한 admin, auth, contenttypes, sessions 에 대해서도 변경 사항이 있는지 점검하는 것을 볼 수 있습니다. ImageCollector 모델을 만들면서 지정한 max_length 지정 값은 auth 테이블에도 업데이트가 필요한 모양입니다. 알아서 잘 챙겨주니 참 고맙습니다. :-)
% python3 manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, myfirstapp, sessions
Running migrations:
Applying auth.0012_alter_user_first_name_max_length... OK
Applying myfirstapp.0001_initial... OK
이렇게 이번 포스팅에서는 기본 테이블을 생성하고 프로젝트에서 사용할 테이블을 생성해 보았습니다. 이렇게 만든 테이블을 확인하는 쉬운 방법은 장고가 제공하는 Admin 사이트를 이용하는 것입니다. 다음 포스팅에서는 Admin 사이트 접근을 위한 수퍼유저 계정의 생성을 해보고 생성된 ImageCollector 테이블에 간단한 샘플 데이터를 넣어보도록 하겠습니다.
