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 환경 변수를 지정해 보시기 바랍니다!
애플실리콘 기반의 맥북이 등장하면서 세상이 참 행복해졌습니다. 베터리도 오래가고 이륙하지도 않고... 이렇게 쾌적한 맥 운영체제는 간만에 느껴보는 즐거움이었습니다. 하지만 의외의 장소에서 복병을 만나게 될줄은 몰랐고 비슷한 짜증을 경험할 수 있는 누군가(아마도 미래의 나...)를 위해 메모를 남겨 둡니다. 뜬금 없이 왜 애플실리콘 이야기인가...는 글을 읽으시면서 알 수 있게 됩니다.
맥 환경에서 운영체제 패키지 관리를 위해 Homebrew를 보통 사용하게 됩니다. python의 유명한 라이브러리 중 하나인 magic을 사용하기 위해서는 운영체제 환경에 libmagic 패키지를 설치해 둘 필요가 있습니다.
virtualenv 로 가상 환경 구성 및 activate
pip install 로 requirements.txt의 항목 설치
를 하고 디버깅을 시작하는데 import magic 에서 에러가 발생했습니다. 가상 환경에서 magic 패키지가 잘 설치되어 있고 brew 로 libmagic 설치를 확인해봐도 아무런 문제가 없는데 python이 계속 libmagic이 설치되었는지 확인하라고 짜증을 내더군요. 네, 저도 짜증이 나기 시작했습니다.
% python3
Python 3.8.2 (default, Apr 8 2021, 23:19:18)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import magic
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "......./venv/lib/python3.8/site-packages/magic.py", line 176, in <module>
raise ImportError('failed to find libmagic. Check your installation')
ImportError: failed to find libmagic. Check your installation
구글과 함께 문제의 원인과 해결방법을 찾아보면 대부분 패키지가 잘 설치되었는지 확인해봐라, brew 로 libmagic 설치하면 된다 류의 답변이 대부분입니다. 하지만 그 어떤 방법도 동작하지 않았습니다. 왜냐하면 python 패키지든 OS 패키지든 필요한 건 문제없이 다 설치되어 있었기 때문입니다.
두가지 방향으로 다시 조사를 시작했습니다. 범인은 brew와 pip 둘 중 하나일 것이라고 보고 brew에서 설치하는 libmagic과 pip를 통해 설치하는 magic(패키지명은 이것도 libmagic입니다)에 무슨 문제가 있는가... 하는 접근이었습니다. 먼저 발견한 흥미로운 단서는 brew에서 나왔습니다.
https://docs.brew.sh/FAQ
애플실리콘이 등장하면서 homebrew가 사용하는 기본 prefix 경로가 바뀌었다는 이야기가 FAQ에 등재되어 있었습니다. 기본 경로가 달라졌다는 것은 brew를 통해서 설치되는 패키지들도 경로가 달라졌다는 말이 됩니다. 그래 뭐 바뀌었겠지... 하다가 문득, python libmagic 패키지가 절대경로로 라이브러리를 참조하나? 싶은 생각이 들었고 python libmagic의 github 저장소를 들러보았습니다.
python libmagic 패키지가 운영체제의 libmagic 라이브러리를 참조하는 코드는 하드 코딩된 몇 가지 절대 경로를 탐색하도록 만들어져 있었습니다. 그 경로중 하나는 바로 brew가 인텔과 애플실리콘 환경에서 변화가 생긴 바로 그 경로였습니다. 오우... 코드에 기여할 수 있는 것인지 혹은 이미 이슈가 올라왔는지...는 조금 후에 생각하기로 하고 libmagic의 설치 경로를 확인해보고 symlink를 만들어 추정이 맞는지 시험해 보기로 했습니다.
(venv) % brew info libmagic
libmagic: stable 5.40 (bottled)
Implementation of the file(1) command
https://www.darwinsys.com/file/
/opt/homebrew/Cellar/libmagic/5.40 (339 files, 8.4MB) *
Poured from bottle on 2021-05-18 at 15:25:48
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/libmagic.rb
License: Cannot Represent
==> Analytics
install: 13,403 (30 days), 39,666 (90 days), 127,530 (365 days)
install-on-request: 3,672 (30 days), 11,365 (90 days), 34,209 (365 days)
build-error: 0 (30 days)
우려했던, 그리고 Homebrew FAQ에서 알려줬던 것처럼 운영체제 패키지는 /opt/homebrew/Cellar/libmagic/{버전} 경로에 설치가 되어 있었습니다. 해당 경로에 진입하여 libmagic.dylib 의 정확한 경로를 확인하고 /usr/local/lib 로 이동해서 symlink 를 만들었습니다.
symlink 까지 만들어주고 다시 코드를 실행하니 import magic 구문에서 문제가 더 이상 발생하지 않았습니다. 보통 python 에서 패키지 문제가 생기면 1) 가상 환경에 설치가 되었는지 보고, 2) 버전을 타는 문제가 있나 확인하는 정도로 문제가 해결되었는데 이번 케이스는 좀 그렇지 않아 시간을 은근히 쓸 수 밖에 없었네요. 금방 한것처럼 보이지만 구글링을 얼마나 했던지...
새로운 개발 장비가 생기면 이전에 사용하던 장비의 환경과 동일하게 준비하는 것이 은근 번거롭습니다. 한동안 손대지 않고 있던 파이썬 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 으로 만들어졌다 정도의 특징들이 있는 것 같네요!
이제 본격적으로 프로젝트의 내용물을 채워보도록 하겠습니다. 별도의 외부 데이터베이스를 사용하지 않고 기본적으로 제공되는 파일 기반의 데이터베이스인 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 테이블에 간단한 샘플 데이터를 넣어보도록 하겠습니다.
