Python 프로젝트를 export 또는 import하는 방법
1. pip install을 사용한다.
2. module관리 도구를 사용한다.
3. git clone을 한다.
1. Pip install 사용하기
# 패키지 구조 만들기
# pip로 github프로젝트에서 install해오기
# setup.py 와 requirements.txt의 차이
- setup.py : pip install로 사용하는 일반 사용자를 위한 최소 설치 요구사항
- requirements.txt : 개발자를 위한 설치 요구사항
https://packaging.python.org/discussions/install-requires-vs-requirements/
# setup.py 작성하기
from setuptools import setup, find_packages
with open('requirements.txt') as f:
requirements = f.read().splitlines()
with open("README.md", "r") as fh:
long_description = fh.read()
setuptools.setup(
name="simple_scheduler", # 이 패키지를 설치/삭제할 때 사용할 이름을 의미한다. 이 이름과 import할 때 쓰이는 이름은 다르다.
version="0.0.1",
author="Donghyun Kwak",
author_email="donghyun.kwak@naver.com",
description="A simplest scheduler for automated data preprocessing and nlu model training.",
long_description=long_description,
long_description_content_type="text/markdown",
url="https://github.com/dhkwak/simple_scheduler",
packages=setuptools.find_packages(),
classifiers=[
"Programming Language :: Python :: 3",
"License :: OSI Approved :: MIT License",
"Operating System :: OS Independent",
],
python_requires='>=3.6',
install_requires=requirements,
)
https://packaging.python.org/tutorials/packaging-projects/
https://docs.python.org/3.6/distutils/setupscript.html
https://www.jetbrains.com/help/pycharm/creating-and-running-setup-py.html
# requirements.txt 작성하기
requirements.txt에는 내가 확실하게 실행을 보장할 수 있는 package와 그 버전을 명시해야한다.
버전명시 방법
- 상세규칙
# pip install시, .py 이외의 파일도 같이 설치되도록 만드는 방법
https://stackoverflow.com/questions/1612733/including-non-python-files-with-setup-py
이때 package_data의 경로에는 패키지명을 제외한 그 하위 디렉토리가 와야한다.
[http://www.ianbicking.org/docs/setuptools-presentation/ 의 22page참조]
# github source에서 바로 설치해야하는 경우
# github source의 특정 브랜치 혹은 특정 commit hash를 설치해야하는 경우
# pip install <패키지명> 으로 설치하게 하기
# python setup.py install로 설치한 것을 uninstall하기
# Local 경로에 있는 package 설치하기
# Editable mode로 설치하기
Egg란 무엇이고 왜 필요할까?
2. module관리 도구를 사용한다.
# git-submodule과 git-subtree의 핵심 차이점
일단 이 둘은 완전한 대체제가 아니고, 어떤 방식으로 사용할 지 목적에 맞게 선택해야하는 도구이다. 기본적으로 submodule은 module repo의 commit hash만 link하는 반면, git-subtree는 기본적으로 module의 소스코드 전체를 포함시킨다. 즉 submodule은 server를 통해야하는 반면, subtree는 decentralized되어 있다.
비교
submodule은 library의 remote에 push할 때는 편리하지만, pull 할 때는 불편하다.
subtree에서는 library의 remote에 push할 때는 불편하지만, pull 할 때는 편리하다.
submodule은 library 내의 변경사항을 library의 remote에 push하지 않고선, 본 프로젝트의 remote repo에서는 관리할 수 없다.
subtree에서는 library 내의 변경사항을 library의 remote에 push하지 않고도, 본 프로젝트의 remote repo에서도 관리할 수 있다.
library내의 변경사항을 library remote repo를 통해서 관리할 때 --> Submodule
library내의 변경사항을 프로젝트의 remote repo를 통해서 관리할 때 --> Subtree
결론: Subtree가 일반적으로 더 쓰기 편하다!
# git-submodule
submodule은 git에서 제공하는 default module관리 도구이다. 만약 submodule을 사용한다면, 절대로 local project을 위한 submodule의 소스코드 변경을 해선 안된다. git-submodule은 library배포와 유사한 개념으로 fixed version의 module이 배포되는 것을 가정하고 있다. 따라서 오직 local project를 위해서 module을 수정하기 시작하면 git-submodule으로 처리할 수 없는 불편한 요소가 매우 많아, 가능하면 이런 식으로사용하지 않기를 권장한다.
장점
- submodule은 library개발에 특화되어 있다. submodule을 쉽고 편하게 git pull을 하여 최신버전으로 update할 수 있고, 체계적으로 submodule의 버전을 나의 repo에서 관리할 수 있다. 또한 submodule에서 발생한 수정사항을 즉, library의 업데이트가 생기면 submodule의 remote repo로 쉽게 push할 수 있다는 점이 있다.(단, 이것을 내 프로젝트의 remote repo로 push하게 되면 크리티컬한 단점 3번이 발생한다.)
단점
1. .git에서 local submodule repo의 경로가 따로 관리가 되기 때문에, local에서 repo 위치를 바꿀 경우 매번 직접 gitdir을 수정해주어야 한다.
2. 기본적으로 submodule의 내용을 웹에서 볼 수 없다. (그러나 이는 git submodule add --force <url> <path>; git submodule update로 해결할 수 있긴하다.)
3. submodule에서 내 프로젝트만을 위한 코드 변경을 할 경우, 이를 제대로 관리할 수 없다. 원칙적으로 submodule내에서의 수정은 submodule의 remote repo를 통해서만 트랙킹해야한다. 만약에 이를 무시하고 내가 수정한 submodule commit을 내 프로젝트의 remote repo에 push를 해버릴 경우, 더이상 submodule의 소스코드를 웹에서 보거나 관리하는 것이 불가능해진다.
4. 수없이 많은 에러. 이 부분은 어쩌면 submodule사용에 매우 숙달될 경우 발생이 덜 할 수 있다. 그러나 내가 매번 항상 겪는 문제는 새로이 git clone을 하면서 아무리 --recursive-module을 입력해도 submodule이 딸려오지 않고, submodule에서 pull을 아무리해도 가져와지지가 않는다.
# git-subtree
장점
단점
3. git clone을 한다.
# 그다음 child repo의 .git을 삭제하고 일반 module로 포함한다.
Submodule에 비해서, git clone으로 그냥 다른 패키지를 가져와서 쓰는 것은 사용성 측면에서 훨씬 편하다. 유일한 단점은 가져온 repo는 git으로 관리해주지 않는다는 것이다.
만약 해당 child repo를 많은 프로젝트에서 재사용하지 않는다면 이는 생각보다 별로 문제가 되지 않는다. 그러나 반대로 해당 child repo를 반복해서 재사용하며, 업데이트가 계속 이루어지는 경우, 이 방식은 매우 매우 불편하다. 왜냐하면 child repo에서 업데이트가 일어날 경우, 매번 수동으로 git clone한 다음, .git을 삭제하는 일을 반복해야하기 때문이다.
* 주의사항: 이 방식을 사용할 경우, Initial Commit이 원래 repo의 어떤 commit hash인지 반드시 기록해두어야 한다.
# Parent repo의 .gitignore에 해당 module을 등록한다.
'Development > Python' 카테고리의 다른 글
Python 파일을 exe파일로 컴파일하기 (0) | 2020.02.04 |
---|---|
Python Concurrency Programming (4) | 2020.01.09 |
Python Coding Convention: PEP 8 (0) | 2019.12.17 |
Python game programming. Pygame + PyBox2D (0) | 2017.01.16 |
Python에서 유용한 라이브러리 (2) | 2016.02.23 |
댓글