<p>네임 스페이스 패키지에 대한 pip install --editable 및 pip install clash</p>

여기에 같은 문제 :(

이 버그를 테스트하는 코드를 게시했습니다. http://public.hg.stephane-klein.info/hgwebdir.cgi/test_pip_namespace_bug_3/

여기서 문제의 근원은 setuptools에 네임 스페이스 패키지를 작동시키는 두 가지 방법이 포함되어 있다는 것입니다. __init__.py 방법 (문서화되어 있으며 사람이 사용할 수 있음)과 ...-nspkg.pth 파일 방법 --single-version-externally-managed (pip가 사용함)에서만 사용됩니다. 두 방법은 서로 호환되지 않습니다.

IRC에서 mitsuhiko 및 다른 사람들과 논의한 후, pip를위한 최상의 (부분) 솔루션은 "pip install -e"가 각 개발 설치 패키지에 대해 표준 setuptools ... nspkg.pth 파일의 수정 된 버전을 추가하도록하는 것입니다. . (필요한 수정은 sitedir 대신 개발 달걀 링크 경로를 사용하고, 개발에 설치된 네임 스페이스 패키지에는 init .py가 있으므로 init .py 검사를 완전히 건너 뛰는 것입니다). 즉, pip는 최소한 자체와 호환됩니다 (pip 설치 및 pip 편집 가능 설치 네임 스페이스 패키지가 함께 작동 함). Pip 설치 및 setuptools / 분산 설치 네임 스페이스 패키지는 호환되지 않습니다.

나도 최근에 이것에 물렸다. 이로 인해 발생하는 또 다른 문제는 네임 스페이스 패키지에 대해 __init__.py 가 설치되지 않았기 때문입니다 (해당 네임 스페이스에 패키지를 하나만 설치했고 단일 버전이 외부에서 관리되었다고 가정). 코의 모듈 검색을 중단합니다. 코의 잘못 일 수도 있지만 디렉토리에 __init__.py 가 포함되어 있지 않으면 Python 패키지가 아니라고 예상하는 것이 합리적이라고 생각합니다.

나는 pip가 어떻게 든 nspkg.pth를 모두 죽이고 __init__.py 설치해야한다고 생각합니다. 패키지 자체가 올바르게 디자인 된 한 (즉, __init__.py 는 extend_path / declare_namespace를 제외하고 비어 있음) 문제가되지 않습니다. --single-version-externally-managed는 시스템 패키저를 염두에두고 설계되었지만 처음에는 pip를 사용하지 않을 것입니다. 그래서 너무 방해하지 않고이 동작을 완전히 비활성화 할 수있는 방법이 있는지 궁금합니다.

'--single-version-externally-managed'에서 전환하는 경우 +1 : 해당 옵션은 pip의 사용 사례를위한 것이 아닙니다. pip가 최소한 easy_install만큼 좋은 설치 작업을 수행 할 수 없다면 그 목적은 무엇입니까?

--single-version-externally-managed 완전히 전환하는 것은 발생하지 않습니다. 플랫 설치는 기능입니다. 네임 스페이스 패키지의 경우에만 이러한 문제를 방지하기 위해 고려할 가능성이 있습니다. 나는 그것을 좋아하지 않지만 setuptools / distribute에 내장 된 두 가지 유형의 네임 스페이스 패키지 지원 사이의 본질적인 비 호환성을 고려할 때 훌륭한 옵션은없는 것 같습니다.

--single-version-externally-managed 가 "pip의 사용 사례를위한 것이 아닙니다"라고 말하는 것은 잘못된 것과 붉은 청어 사이의 어딘가에 있습니다. 이 플래그는 easy_install이 아닌 다른 도구로 관리되는 단일 버전 설치를 허용하기위한 것입니다. 그것이 바로 pip가 그것을 사용하는 이유입니다. setuptools 작성자가 원래 (그리고 부정확하게) 시스템 패키지 작성자 만이 그러한 기능에 관심을 가질 것이라고 생각했다는 사실은 관련이 없습니다.

여기서 파손은 해당 플래그가있는 네임 스페이스 패키지에 대해 setuptools가 사용하는 기술에 내재 된 버그입니다. 버그는 원래 의도 한 대상인 시스템 패키지 작성자가 플래그를 사용할 때와 똑같이 존재합니다 (처음에는 " setup.py develop "설치된 패키지 및 시스템 패키지 설치 네임 스페이스 패키지).

이 버그도 발생하고 있습니다. 나는 이것이 여기 남아있는 해결 불가능한 버그 중 하나라고 생각합니다. 오 잘.

네임 스페이스 패키지가 관련되어있을 때 --single-version-externally-managed 를 피하기위한 패치를 수락 할 것입니다.이 문제를 해결할 수있을 것입니다. 나는 현재 그 패치를 작성할 계획이 없습니다.

--single-version-externally-managed 를 사용하지 않기 위해 pip install 전달할 수있는 옵션이 어떻습니까? 나는 easy_install처럼 ./pip/req.py:568 와 모든 패키지가 이제 egg dir에 설치된 것을 주석으로 처리하여 테스트합니다. 때로 pip와 easy_install을 모두 사용하여 site-packages 가 일부 패키지와 혼합되지 않도록하고 일부는 그렇지 않은 경우이 작업을 수행하고 싶습니다.

나는에 문제가 표시되지 않습니다 --egg 옵트 아웃 옵션을 --single-version-externally-managed .

https://github.com/k4ml/pip/commit/93cd6b16207d2eba201a7fc3126624b616f5e6f9

내가 올바른 방향으로 움직이고 있다면 누군가 코멘트를 할 수 있습니까? 이것은 처음으로 pip 코드를 해킹하는 것이므로 이것은 몇 분 동안 일부를 엿볼 때를 기반으로합니다. pip install --egg somepackages 모든 것을 단일 에그 디렉토리에 설치합니다.

내가 올바른 방향으로 움직이고 있다면 누군가 코멘트를 할 수 있습니까?

나에게 잘 어울려요. 테스트가 필요합니다. 테스트는 대부분 높은 수준입니다.
ScriptTest를 사용한 통합 테스트는 다음을 기반으로 작성하기 쉬워야합니다.
기존 예. 이 경우 설치를 테스트하고 싶을 것입니다.
샘플 패키지는 플랫 설치가 아닌 .egg 파일을 생성합니다.
사이트 패키지. 로컬 파일 시스템에서 패키지를 설치해야합니다.
네트워크가 아님 : tests/packages/FSPkg 이 (가) 정상적으로 작동합니다. 첨가
tests/test_basic.py 대한 테스트는 괜찮습니다.

감사!

풀 요청-https: //github.com/pypa/pip/pull/541

또한 pip.conf에서이 플래그를 설정할 수 있도록 할 생각입니다. 그것에 대해 어떻게 생각하십니까?

또한 pip.conf에서이 플래그를 설정할 수 있도록 할 생각입니다. 그것에 대해 어떻게 생각하십니까?

풀 리퀘스트에 대해 논의합시다.

하나의 해결 방법을 제공하는 병합 된 풀 요청 # 541. @ k4ml 감사합니다!

주의 :이 문제를 해결하기 위해 추가 된 --egg 옵션은 대체 해결 방법이 제공되지 않고 제거 될 수 있습니다. # 1749에서 토론 참조

이 문제를 실제로 재현하는 스크립트는 다음과 같습니다.

https://gist.github.com/Ivoz/d9bff05069e0ec53e6ea

나는 --egg 솔루션의 열렬한 팬은 아니지만 이것에 대한 덜 성가신 해결 방법이 필요합니다.

해결 방법이 없으면 개발 중에 --editable을 한 번 사용할 수 없으며 편집하고 테스트 할 수 있습니다. 내 코드를 저장할 때마다 pip install -I --no-deps . 실행해야합니다. 정말 오래되고 깨지기 쉽습니다 (읽기 : 가끔 잊어 버림).

이 전체 문제가 나타나는 방식의 문제 중 일부는 침묵이라는 것입니다. 모듈이 설치되어 있고 pip가 모듈이 있다고 알려주더라도 모듈을 가져올 수 없습니다.

해당 네임 스페이스에 편집 할 수없는 패키지가 이미 설치되어있는 네임 스페이스의 일부로 편집 가능한 패키지를 설치하려는 경우 pip가 불평하게 만드는 것은 긍정적 인 단계입니다. 또는 해당 네임 스페이스의 편집 가능한 패키지가 이미 설치된 네임 스페이스의 일부인 편집 불가능한 패키지를 설치하려는 경우 불만을 제기합니다.

또 다른 옵션은 실제로 네임 스페이스 패키지와 편집 가능한 설치가 항상 작동하도록하려면 네임 스페이스 패키지가 편집 가능한 상태로 설치된 경우 pip가 해당 네임 스페이스의 다른 모든 패키지를 원하는 패키지와 함께 편집 가능한 것으로 재구성 할 수 있습니다.

이 문제를 해결하기 위해 setuptools https://bitbucket.org/pypa/setuptools/issue/250/develop-and-install-single-version 에서 2 개의 제안을 제출했습니다

퍼팅

import pkg_resources; pkg_resources.fixup_namespace_packages ( '')

사이트 패키지의 .pth 파일에서 pip install -e 설치된 항목이 올바르게 작동하도록하는 데 충분합니다.

이는 또한 편집 가능한 것으로 설치된 두 패키지 모두 최상위 네임 스페이스가 동일한 두 패키지에 영향을줍니다. 두 번째 패키지 설치가 손상되었습니다.

우리는 모든 애플리케이션에 전역 네임 스페이스를 사용하므로이 문제는 약간 어렵습니다 (+ Windows 배포 플랫폼에 컴파일러가 없기 때문에 필요한 설정 도구가 휠을 지원하지 않는 문제). 또한 모든 권장 솔루션은 Python 3.4를 사용한 설정에서 실패하는 것 같습니다.

pip install -e 가 편집 할 수 있어야하는 프로젝트에 대해 setup.py develop 를 실행한다는 것을 인식 한 후 setuptools 프로 시저에 연결하여 * .pth 파일을 작성했습니다.이 파일은 파이썬 프로세스를 실행할 때 네임 스페이스 패키지를 "도입"합니다. 시작합니다. 이렇게하면 setuptools 18 및 pip 7.1.0을 사용할 때 문제가 해결됩니다.

이를 수행하는 방법을 보여주는 예제 setup.py 파일은 여기에서 찾을 수 있습니다.
https://gist.github.com/cbrand/a1624ac3e9c81ce45fcb

다른 분들에게도 도움이 되었으면합니다.

오늘도이 문제를 만났는데 빌드 아웃에서 virtualenv + pip로 전환하는 것을 차단하고 있습니다.

문제를 보여주는 작은 데모를 만들었습니다. 테스트하려면 .tar.gz의 압축을 풀고 그 안에 {{run-me}} 스크립트를 실행하십시오. 수정 사항을 테스트 할 때 유용 할 수 있습니다.

나는 또한이 문제에 부딪 치고있다.

이해하려고 노력하는 동안 https://github.com/pypa/pip/issues/3#issuecomment -1659959에서 @carljm 이 제안한 솔루션을

나는 그 접근 방식을 수동으로 실험했고 잘 작동하는 것 같습니다. # 3160에 설명 된 것처럼 네임 스페이스 패키지가 누락 된 얕은 소스 트리 문제를 동시에 해결할 수 있습니다.

그래서 나는 그 접근법이 여전히 유효한 것으로 간주되는지, 그것을 구현하려는 시도가 있었는지, 그리고 이것에 대한 패치를 고려할 것인지 궁금합니다.

그럼 ...이 문제가 가까운 장래에 고쳐질 희망이 없나요?

pkg_resources.get_distribution() 의 일부 부작용으로 인해 가져 오기가 작동합니다. 파이썬 쉘이 실패하는 동안 진입 점을로드 한 코드가 올바르게 작동했을 때 이것을 발견했습니다.

이것은 또한 ipython 쉘이 패키지를 가져 오는 데 문제가없는 이유를 설명 할 수 있습니다.

이 버그가 5 년 후에도 명확한 해결 방법없이 열려 있다는 사실에 놀랐습니다.

프레임 워크를 하나의 통합 프레임 워크로 결합하는 것이 작업이라면 pip는 작업을 짜증나게 만듭니다. 이 버그로 인해 작업을 진행하는 방법을 솔직히 알지 못합니다.

이것은 주로 자원 봉사 프로젝트에서 문제를 해결하기 어렵습니다.
pip가 올바르게 수행 할 수 있도록 setuptools에 필요한 지원을 자유롭게 추가하십시오.

Brandon Github [email protected] 은 다음과 같이 씁니다.

이 버그가 5 년 후에도 명확한 해결 방법없이 열려 있다는 사실에 놀랐습니다.

네, 유감입니다.

프레임 워크를 하나의 통합 프레임 워크로 결합하는 것이 작업이라면
pip는 당신의 직업을 짜증나게 만듭니다. 솔직히 어떻게 진행해야할지 모르겠어요
이 버그로 인해 내 작업.

나는 최근에 위에서 언급 한 fixup_namespace_packages ( '') 해킹을 적용했고
작동하는 것 같습니다 : Venv의 사이트 패키지 내에 z.pth 만들었습니다.
import pkg_resources; pkg_resources.fixup_namespace_packages('')

시도할만한 가치가 있습니다, IMHO.

여기에 또 다른 충돌!

모든 골수 패키지는 네임 스페이스 (일부 패키지는 최대 4 개 또는 5 개로 채워짐)를 사용하며,이 특정 문제는 새로운 사용자가 개발 도구를 설정하는 데 도움이 될 때 내 존재에 약간의 골칫거리였습니다. . 나는 이것을 사용하는 60 개의 패키지를 부끄러워했습니다. entry_points 메모도 흥미 롭습니다. 사실상 네임 스페이스에 기여하는 모든 패키지가 entry_points 도 기여하기 때문입니다.

pip 접근 방식은 _every_ 패키지가 설치되고 편집 가능한 디스크에서 네임 스페이스에서 협력하는 경우에만 작동합니다. 하나의 패키지가 pip를 통해 편집 불가능하게 설치된 경우, 전체 원사 공이 새로운 사용자에게 매우 둔감 한 증상으로 풀리기 시작합니다. (예 : 간헐적으로 가져올 수있는 모듈, 상위 네임 스페이스 가져 오기 및 namespace.__path___ 확인에 대한 일반적인 온 전성 검사는 테스트에서 문제가되는 패키지를 신속하게 식별했습니다.) 적절하게 pip 설치된 패키지와 순수 setup.py develop 'd 혼합 그러나 소스 (pip 회피)는 작동하는 것처럼 보입니다.

또한 단일 네임 스페이스 제공 패키지가 세 가지 다른 방법으로, 때로는 모두 동시에 설치 될 수있는 이상한 상황에 처할 수있는 것 같습니다. ( pip uninstall 반복적 인 호출은 각각 더 많은 파일을 찾는 것은 불행한 일입니다.) pip install -e 사용할 때 종속성 설치도 일관성이없는 것처럼 보입니다. 대부분의 경우 우리는 적절하게 압축이 풀린 네임 스페이스 (설치됨), pth-link 파일 (편집 가능 설치됨)으로 끝나고, 어떤 경우에는 zip_safe 에도 불구하고 압축 된 .egg 설치했습니다 zip_safe 는 해당 종속 패키지에서 False 이고 Pypi에서는 .egg 배포가 제공되지 않습니다.

네임 스페이스 문제에 대한 좌절감은 가상 환경이 처음부터 다시 시작되도록 네 번째 시간이 지나면 절정에 이릅니다. ;)

해결책은 아니지만 몇 가지 메모를 남겼습니다. '편집 가능한'패키지, 네임 스페이스 패키지 및 일반 패키지를 혼합 할 때 buildout + mr.developer에 더 많은 행운이 있습니다.

@lelit이 언급 한 수정 해킹이 일부 패키지에서 작동하는 것처럼 보이지만 일부 패키지 / 빌드도 망가집니다.

pip 설치 및 편집 가능 모드를 가지고 놀다가 @carljm (편집 가능한 모든 패키지에 -nspkg.pth 파일 추가)과 동일한 아이디어를

PEP420이 구현 된 최신 버전의 Python에서 여전히 문제입니까? (읽기 : 최신 버전의 파이썬으로 전환하는 것이 도움이 될까요?)

PEP420 스타일을 사용하면 편집 가능 모드에서 여러 번 효과적으로 도움이되었습니다.

안타깝게도 자체 결함이 있습니다. 예를 들어 setuptools의 find_packages 는이를 지원하지 않습니다 .

-    packages=find_packages('src'),
+    packages=['toplevel.child.' + package
+              for package in find_packages('src/toplevel/child/')],

아무도 편집 가능한 모든 패키지에 -nspkg.pth를 추가하는 것을 구현하지 않은 것 같습니다.

이 기능에 대한 지원을 추가하고 Python 3.5 이상에서 PEP-420 패키지와 공존하는 Setuptools 31 을 확인하십시오.

궁금한 사람을 위해 pip install , pip install -e , python setup.py install 및 python setup.py develop 네임 스페이스 패키지가 작동하는 방법에 대한 전체 목록이 있습니다.

https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md

tl; dr : pip 사용하여 네임 스페이스의 다른 모든 패키지를 설치 한 경우 pip install -e 및 python setup.py develop 를 사용할 수 있습니다.

이 문제를 종료하겠습니다. setuptools 31은 우리의 복제 스크립트를 위해 이것을 수정 한 것으로 보이며, 그 이상으로는 pip가 여기서 할 수있는 일이 없습니다.

뿡뿡
https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md 에서 결과를 얻기 위해 사용 된 pip 및 setuptools 버전은 무엇입니까?

@dstufft 수정되었다고 생각 하지만 @jonparrott 의 호환성 테이블이 증거로 다시 실행되는 것을보고 싶습니다. 저는 거의 7 년이 지난 티켓에 대해 최선을 다하고 최악의 경우 계획을 세우기를 바라며 광범위한 실패 시나리오를 가지고 있습니다. 이 문제의 광범위한 역사를 감안할 때 신뢰도가 높지 않고 직접 nox 제품군을 다시 실행하면 실패는 실제 해결 방법이 없음을 나타냅니다.

@jonparrott 의 예에서 실패한 경우는 " python setup.py install 직접 사용 (예상되는 Python 2의 PEP 420 실패 제외)으로 정리할 수 있습니다. 이는 pip가 관련되지 않은 경우에도 실패합니다. 전혀 (예 : python setup.py install + python setup.py develop ).

이 티켓은 pip install . 및 pip install -e 또는 python setup.py develop 조합을위한 것입니다.

@jonparrott 가 이미 게시 한 그래프는이 티켓이 해결되었으며 여기에 남아있는 모든 문제는 pip가 아닌 python setup.py install 의 문제임을 나타냅니다.

테스트를 다시 실행했는데 모든 것이 처음 실행 한 것과 동일합니다. @dstufft 의 평가에 동의합니다. pip는이 문제를 해결하기 위해 할 수있는 모든 일을했습니다.

@ piotr-dobrogost 테스트는 둘 다 최신 버전을 사용합니다. 이 글을 쓰는 시점에서 pip 9.0.1 및 setuptools 34.3.2.