Pip: 새로운 해석기: 출시, 피드백 루프 및 개발 흐름

어떻게 계획했는지 모르겠지만 한 가지 의견은 새 코드와 현재 코드 간에 가능한 한 많은 코드를 공유하고 작업하는 동안 현재 코드를 리팩토링하도록 권장한다는 것입니다. 새 코드 경로와 현재 코드 경로 간에 더 많은 공유를 허용합니다.

한 가지 이유는 더 많은 코드를 공유하는 경우 새 동작을 껐다가 켰을 때 손상될 가능성이 적기 때문입니다. 대처해야 할 행동의 많은 잠재적인 차이.

여기에는 사용자에게 사용해 보고 피드백을 제공하도록 요청하는 CTA가 포함됩니다.

새로운 기능에 대한 사전 피드백을 받은 실적은 상당히 좋지 않습니다. 우리는 베타 릴리스를 시도하여 사람들이 문제가 발생했을 때 사용할 수 있는 "옵트아웃" 플래그가 있는 새로운 기능을 출시하고 변경 사항을 깨는 대대적인 홍보 활동을 시도했지만 그 중 아무 것도 효과가 없었던 것 같습니다.

내 개인적인 느낌은 "사용 가능하게 하고 피드백을 요청하는 것"이 ​​우리가 이전에 시도한 것에 대한 흥미로운 변형이지만 궁극적으로 큰 차이가 없을 것이라는 것입니다. 너무 많은 사람들이 자동화된 빌드 파이프라인에서 기본 옵션이 있는 최신 pip를 사용하고 새 pip 버전으로 이동하기 전에 테스트하지 않습니다(PEP 517에서 이를 확인했습니다).

이 기능에 대한 대규모 "실제" 테스트 작업을 수행하거나 (더 나은 방법으로) 테스트 인프라를 개발하기 위한 리소스를 얻기 위해 PSF 보조금을 받을 수 있는지 궁금합니다. 이러한 프로젝트에는 새로운 pip 버전이 문제를 일으키지 않도록 테스트 경로를 설정할 수 있도록 워크플로 및 구성을 알려주는 프로젝트에 대한 호출이 포함될 수 있습니다. 아니면 더 나은 사용자 테스트 프로그램을 설정하는 데 도움이 되는 새로운 기능에 대한 베타 테스터를 얻는 것과 같은 커뮤니케이션 측면에서 누군가를 경험하도록 보조금을 사용하시겠습니까?

git/GitHub 측면에서 이것은 아마도 pip 내에서 최초의 "실험적" 기능 구현일 것입니다.

무슨 말인지 100% 확신할 수 없습니다. 우리는 "이전 방식"이 여전히 존재하는 동안 추가된 과거에 확실히 새로운 기능을 가지고 있었습니다. 우리는 "기본적으로 꺼져 있고 사용해 볼 수 있도록 설정"하는 경향이 있지는 않지만 그 이유는 대부분 피드백을 얻을 수 있는 좋은 방법을 찾지 못했기 때문입니다(위 참조).

이 포스트 하나를 쓰는 데 60분 정도(re-re-re-re-re-)를 썼으므로 이제 뉴욕의 장소를 살펴보겠습니다! 빠른 응답이 없으면 관광 모드에 있기 때문입니다.

새 코드와 현재 코드 간에 가능한 한 많은 코드를 공유하고 새 코드 경로와 현재 코드 경로 간에 더 많은 공유를 허용하도록 작업하면서 현재 코드를 리팩터링하는 것이 좋습니다.

분명히! 이것이 내가 #5051을 앞에 두는 이유의 80%입니다. 저는 빌드 로직에 축적된 많은 기술적 부채를 갚아 재사용(전부?)하기가 더 쉽도록 하려고 합니다. 코드의 무리는 :fire: 해야 하고 나머지는 확실히 합리적인 만큼 재사용해야 한다는 데 동의합니다.

우리는 "기본적으로 꺼져 있고 사용해 볼 수 있도록 설정"하는 경향이 있지 않습니다.

네, 정말입니다. 나는 또한 여기서 개발 흐름에 대해 암시하고 있습니다. IMO 빈 인프라(이후 PR에서 구체화될 raise NotImplementedError() 에 불과한 여러 메서드가 있는 클래스)를 병합해도 괜찮을 것입니다. "experimental/alpha"로 명시적으로 표시된 플래그 뒤에만 사용되는 한 master 분기에 모든 경우(하프 베이크된 구현)를 포함합니다.

다시: 피드백

저는 어리고 멍청하며 낙관적입니다. 저는 이 롤아웃을 옵트인으로 설정하여 능동적인 피드백을 받고 이에 따라 조치를 취하고 싶습니다. "사전적"이라는 말은 알파/베타 기능을 시험해보고 어떤 기능인지 알려주기 위해 시간을 할애하는 사람들을 의미합니다. 나는 우리가 충분한 소음을 내고 전략적으로 사람들을 목표로 삼거나 접근한다면 세부 사항/문제를 해결하는 데 도움이 되는 새로운 기능을 시험해 볼 시간과 에너지가 있는 사람들로부터 좋은 "사전적" 피드백을 얻을 수 있다고 생각합니다.

최근의 "주요" 변경 사항을 살펴보면 사용자가 워크플로가 중단되었을 때 문제를 인식하고 이에 대해 알려주기 위해 연락하는 반응적인 피드백이 대부분이었던 것 같습니다. 그들 중 많은 사람들이 많은 마찰을 일으키는 새로운 기능의 세부 사항을 정리하는 데 도움을 줄 시간이 없었을 수 있습니다. 이것은 또한 우리의 "이탈 예산"[1]에 많은 비용을 들이는데, Python Packaging에 어쨌든 얼마 남지 않았기 때문에 더 지출하고 싶지 않습니다[2].

FWIW, 나는 꽤 눈에 띄는 위치(예: 내 개인 블로그가 아님)에 블로그 게시물을 작성하고, 팟캐스트, 적시에 실행 가능한 이메일 등을 하는 것과 같이 PyPI 출시에서 몇 가지 아이디어를 빌릴 계획입니다. 또한 더 많은 선행 기술을 찾고 있습니다. /통로를 통해 통신합니다. 내가 PyCon에서 배운 (많은!) 것 중 하나는 우리가 사용하지 않는 채널이 있다는 것입니다. 채널은 정보를 퍼뜨리는 데 도움이 되지만 퍼뜨릴 것이 있는지 확인하려고 찾지는 않습니다.

분명히 말해서, 저는 우리가 PEP 517에 대해 취한 롤아웃 접근 방식에 대해 비판하는 것이 아닙니다. 특히 우리 모두가 자원 봉사자라는 사실을 감안할 때 잘 진행되고 있다고 생각합니다. 나는 우리가 배울 수 있는 것과 우리가 겪었던 문제를 피하기 위해 실행 가능한 항목을 보려고 노력하고 있습니다. 이 항목의 대부분은 유지 관리자의 더 많은 작업을 포함하며 내가 이 모든 시간을 이 문제에 대해 생각하는 주된 이유는 이것을 변경 관리를 수행하는 방법에 대한 재미있는 학습 연습으로 보기 때문입니다.

재: 보조금

네, 확실히 교부금/경험이 더 많은 사람을 사용하여 커뮤니케이션, 롤아웃 및 테스트 인프라를 파악하는 데 도움이 될 수 있다고 생각합니다. 그러나 내가 보장할 수 있는 보다 안정적인 주당 시간이 없기 때문에 보조금 작성 작업을 수행하고 내가 지금 할 수 있는 것보다 더 구체적인 계획을 알아낼 사람이 필요합니다.

FWIW, PSF는 PyPA/패키징 관련 커뮤니케이션을 Changeset Consulting과 파악하는 데 도움이 되는 지속적인 계약을 맺고 있으므로 이를 활용할 수 있을까요?

대화에 더 많은 사람들을 추가하기 위한 계획 단계의 초기 단계이기 때문에 의도적으로 사람들을 @-언급하지 않습니다.

각주:

1. @ pganssle이 사용한 정말 좋은 용어인데 제가 확실히 사용할 것입니다.
2. 이것이 제안된 "pip-cli" 패키지의 구현이 있고 롤아웃의 모양에 대한 합리적인 합의가 있음에도 불구하고 #3164를 백 버너에 넣은 이유입니다.

나는 어리고 멍청하고 낙관적이야

:-) 그리고 나는 때때로 너무 늙고 지치고 냉소적입니다. 당신의 철학과 함께 가자, 훨씬 더 좋게 들린다 :-)

분명히! 이것이 내가 #5051을 앞에 두는 이유의 80%입니다. 저는 빌드 로직에 축적된 많은 기술적 부채를 갚아 재사용(전부?)하기가 더 쉽도록 하려고 합니다.

엄청난!

지금 IRC에서 :

[sumanah] pradyunsg: 리졸버에서 더 많은 작업을 더 빨리 완료할 수 있도록 pip 및 패키징 커뮤니티에서 할 수 있는 일이 있습니까?
....
[pradyunsg] 사실, 지금 https://github.com/pypa/pip/issues/6536 에 대한 입력이 작업에 접근하는 방법/사람들로부터 피드백을 받는 방법 등을 파악하는 데 도움이 될 것입니다.
....
[sumanah] pradyunsg: re: New Resolver: Rollout, Feedback Loops and Development Flow #6536 -- 원하는 입력은 다음과 같습니다. 기능 플래그 접근 방식이 좋은 아이디어인가요? pip GitHub 문제가 아닌 다른 메커니즘을 통해 피드백을 받는 것이 좋은 생각입니까? 실제 수동 테스트 및 강력한 테스트 인프라 구축 및/또는 사전 예방적 통신을 얻기 위해 보조금 또는 이와 유사한 것을 받는 것이 좋은 생각입니까?
...
[pradyunsg] 네 -- 제가 제안하는 아이디어가 좋은지. 또한 롤아웃 + 피드백을 보다 원활하게 하는 데 도움이 될 수 있는 추가 아이디어/접근 방법/생각은 굉장할 것입니다.

그래서:

기능 플래그 접근 방식이 좋은 아이디어입니까? 예.

pip GitHub 문제가 아닌 다른 메커니즘을 통해 피드백을 받는 것이 좋은 생각입니까? 예. 덜 전문적인 사용자로부터 덜 구조화된 버그 보고서를 수락하는 자동화된 방법을 찾아야 합니다.

보다 강력한 테스트 인프라가 도움이 될까요? 예, 많이 있습니다. 후원자가 우리 를 도울 수 있는 곳입니다.

PyPA 조정/통신을 돕기 위해 PSF와 기존 계약에 따라 Changeset(저)이 사전 의사 소통을 통해 Pip를 사용하여 보다 체계적인 실제 수동 테스트를 얻을 수 있습니까? 이 롤아웃을 시작할 때까지 계약에 남은 시간이 있다고 가정하면 그렇습니다.

사용자 경험, 커뮤니케이션/홍보 및 테스트에 대해 더 많은 도움을 받기 위해 보조금 또는 이와 유사한 것을 받는 것이 좋은 생각입니까? 예. PSF 보조금 은 NLNet 보조금 ( 30,000유로 미만 요청), 잠재적 으로 과학 보조금을 위한 Chan Zuckerberg 필수 오픈 소스 소프트웨어 및 Mozilla의 MOSS 와 마찬가지로 잠재적 으로 관심 이 있을 것입니다. Packaging WG 는 등록 신청자가 될 수 있습니다. @pradyunsg 또는 @pfmoore 가 "예, 흥미롭게 들리네요"라고 고개를 끄덕이고 싶다면 WG와 함께 이러한 가능성을 조사할 수 있습니다.

@pradyunsg 또는 @pfmoore 가 "예, 흥미롭게 들리네요"라고 고개를 끄덕이고 싶다면,

확실히 흥미롭게 들립니다 :-)

@pradyunsg 또는 @pfmoore 는 "예, 흥미롭게 들리네요"라고 고개를 끄덕이고 싶어합니다.

_ 끄덕끄덕 _ 예, 흥미롭게 들립니다.

보다 강력한 테스트 인프라가 도움이 될까요? 예, 많이 있습니다. 후원자가 우리 를 도울 수 있는 곳입니다.

@brainwane https://github.com/pypa/integration-test도 관련이 있습니다. 이 설정을 하는 것이 자금 조달을 위한 또 다른 잠재적 영역이라고 생각합니다 . https://wiki.python.org/psf/Fundable%20Packaging%20Improvements에 추가해야 합니다.

확인! 저는 패키징 워킹 그룹을 통해 CZI 보조금을 신청하는 것에 대해 PSF 및 Chan Zuckerberg Initiative 사람들과 이야기하기 시작했습니다. 새로운 pip 리졸버가 중요한 이유에 대한 몇 가지 세부 정보를 Fundable Packaging Improvements 페이지 에 추가하고 integration-test 프로젝트를 해당 목록에 추가했습니다. 그리고 저는 우리의 복잡한 올-온-커맨드-라인 패키지 배포/설치 도구 체인을 조사하고, 무슨 일이 일어나고 있고 어떤 일이 일어나야 하는지에 대한 멘탈 모델을 이해하기 위해 사용자와 대화할 수 있는 사용자 경험 전문가의 이름을 모으기 시작했습니다. , 유지 관리자에게 조언합니다.

MOSS, CZI 또는 NLNET에서 보조금을 통해 돈을 받는다면 돈을 받을 수 있을 것입니다. 빠르면 10월이 될 것입니다. PSF에서 직접 보조금을 받는 것이 더 빠를 수 있지만 "현재 우리의 초점은 Python 워크샵, 컨퍼런스(특히 재정 지원) 및 Python 다양성/포용성 노력입니다."

한 가지 고려 사항은 Brett와 운영 위원회의 사람들이 프로젝트 관리에 투자하고 이러한 프로젝트(선별 분류, 프로젝트 관리 등)를 관리하기 위한 일종의 유료 자원 확보에 대해 이야기하고 있으며 PSF와 이야기하고 있다는 것입니다. 곧장. 장기적인 지속 가능성에 대한 이야기를 들었고 거기에 참여하는 것이 좋을 것이기 때문에 연락하여 그들이 무엇을 하고 있거나 생각하고 있는지 알아내는 것이 가치가 있을 수 있습니다.

기능 플래그가 좋고 옵트인이 좋습니다. 고려할 수 있는 한 가지는 사용자에게 리졸버를 시험해 보라고 무작위로 프롬프트할 수 있는지 여부입니다(예: 매우 매우 드물게 한 번에 설치하는 경우에만, 즉 영구적으로 켜도록 강요하지 않음). 그런 다음 리졸버가 얼마나 도움이 되었는지 나타낼 수 있습니다(예: 리졸버에게 어떤 역할을 했는지, 어떤 충돌이 발생하여 해결했습니까?)

예를 들어 자바 스크립트나 녹에서 오는 사람들은 일종의 잠금 파일도 기대하므로 고려해야 할 사항일 수 있습니다.

뛰어들어서 죄송합니다. 앞으로 나아가게 되어 기쁩니다!

내 개인적인 느낌은 "사용 가능하게 하고 피드백을 요청하는 것"이 ​​우리가 이전에 시도한 것에 대한 흥미로운 변형이지만 궁극적으로 큰 차이가 없을 것이라는 것입니다. 너무 많은 사람들이 자동화된 빌드 파이프라인에서 기본 옵션이 있는 최신 pip를 사용하고 새 pip 버전으로 이동하기 전에 테스트하지 않습니다(PEP 517에서 이를 확인했습니다).

바로 이런 이유로 인해 일부 PEP 517 문제에 시달린 사람 중 한 명으로서 저는 실제로 테스트를 위한 옵트인 방식을 보고 싶습니다. 하지만 --no-use-pep517 플래그 문제 이후에 내가 할 수 있는 모든 python 패키징 뉴스 소스를 구독했기 때문에 이런 종류의 것들에 대해서만 알고 있습니다. 내가 말하려는 것은 이런 종류의 뉴스를 퍼뜨리는 것이 어렵고 피드백을 받기 어려운 이유일 것입니다.

정보가 더 잘 보급될 수 있다면 더 많은 사람들이 이것에 관심을 가질 것이라고 생각합니다. 그것이 당신이 찾고 있는 자원이 허용하는 것입니까?

jriddy가 말하는 것을 계속하기 위해, 사람들이 다양한 기능 플래그에 대해 알아야 하고, 각각의 새 플래그에 대해 CI 설정을 변경해야 하는 경우 다양한 기능 플래그를 테스트하도록 하는 것이 정말 어려울 것이라고 생각합니다.

그러나 훨씬 더 할 수 있는 것처럼 보이는 것은 _하나의_ 기능 플래그만 알면 테스트해야 하는 변경 사항의 관점에서 "다음에 나올 내용"을 테스트하는 것입니다. 그런 다음 사람과 회사는 CI를 설정하여 CI도 실행할 수 있습니다(오류로 인한 빌드 실패 없이). 나는 Rust와 비슷한 것을 생각하고 있는데, 이런 종류의 변경이 도구 체인의 "베타" 채널에서 굽고, 다른 CI 채널을 설정하여 베타 도구 체인에서 작업을 실행하고 오류를 누군가에게 보내는 것이 쉽습니다.

핵심은 새로운 개별 기능 플래그에 대해 지속적으로 학습하거나 CI 설정을 수정하거나 수동으로 테스트하는 대신 이 설정에 대해 학습하고 _한 번만_ 수행해야 한다는 것입니다.

그러나 훨씬 더 할 수 있는 것처럼 보이는 것은 알아야 할 기능 플래그가 _하나뿐인 경우,

어떤 의미에서 이것은 이미 --pre 형태로 존재하지 않습니까? pip의 베타 릴리스 채널이 pip install --upgrade --pre pip 를 실행하는 문제일 수 있습니까?

뛰어들어서 죄송합니다. 앞으로 나아가게 되어 기쁩니다!

@techalchemy 제발, 모든 사람들 중 _당신_은 분명히 이 토론에서 투구한 것에 대해 미안해할 필요가 없습니다.

그것이 당신이 찾고 있는 자원이 허용하는 것입니까?

어느 정도 그렇습니다.

reg: 베타 릴리스/pip용 "채널"

@jriddy 와 @chrish42를 불러주셔서 감사합니다. 나는 일반적으로 그것이 확실히 유용하고 중요한 대화라고 생각하지만 이 문제에 대해서는 약간 OT라고 생각합니다. 어쨌든 여기에 한 번 응답하겠습니다. 이 문제에 대해 더 논의하고 싶다면 새 문제를 열어 보겠습니다.

우리는 과거에 이것을 시도했지만 가장 최근에는 pip 10으로 시도했지만 잘 되지 않았습니다. 나는 그것이 앞으로 얼마나 잘 작동할지 약간 회의적이지만, 우리 프로세스의 일부 변경으로 인해 이 작업이 원활하게 진행될 수 있다고 상상할 수도 있습니다. "베타 전용" 기능 세트를 만들 수 있을까요? -X all 를 #5727의 구문으로 상상했습니다. 이 롤아웃 계획의 일부로 선택할 수 있을까요? 이크. 우리는 이것을 알아내기 위해 시간과 에너지를 투자해야 할 것입니다. :)

https://github.com/pypa/packaging-problems/issues/25#issuecomment -520167480에서 언급했듯이 솔버가 pip 경험을 변경하는 방법에 대한 통합된 설명을 갖는 것이 중요하다고 생각합니다. 많은 사람들이 더 엄격한 시스템으로의 전환에 좌절할 것입니다(전체적으로 더 안정적이어야 하지만 현재 차단되지 않는 곳에서 차단될 것입니다.

상황이 어떻게 바뀌었고 왜 좋은 변화인지에 대한 중심 설명이 있으면 화난 사람들에게 훨씬 더 간단하게 대응할 수 있습니다. 링크를 게시하고 추가 질문이 있는지 확인하세요.

프리릴리즈는 좋은 생각입니다. conda에는 시험판 채널인 conda-canary가 있습니다. 우리는 사람들이 conda 변경으로 인해 문제가 발생하는지 확인하는 데 도움이 되는 방식으로 canary에 대해 실행하도록 CI 작업을 설정하도록 권장합니다. 이상적으로는 해당 버전을 출시하기 전에 알려줍니다. 그 채널은 꽤 비참한 실패였습니다. 사람들이 정말로 그것을 사용하는 것처럼 보이는 유일한 시간은 그들이 고군분투하는 일부 버그를 수정하기 위해 최신 릴리스를 얻고 싶을 때입니다. 우리는 의도한 얼리 어답터로부터 많은 보고를 받지 못했습니다. 나는 여전히 프리릴리즈가 좋은 생각이라고 생각합니다. 릴리스가 제대로 진행되지 않고 사람들이 700개의 관리 노드를 깨뜨린 것에 대해 당신에게 화를 낼 때 "글쎄요, 우리가 그것을 출시하기 전에 일주일 동안 사용할 수 있었습니다. 왜 그렇지 않습니까?"라고 말할 수 있기 때문입니다. 700개 노드에 배포하기 전에 이러한 항목을 테스트하고 있습니까?" 당신은 사람들에게 일을 더 잘할 수 있는 기회를 주고 있습니다. 그 기회를 넘기는 것은 그들에게 더 큰 고통을 의미한다는 것을 깨닫도록 도와주십시오. 이는 가치 있는 투자이며 CI의 일부로 수행하는 경우 설정 외에는 시간이 전혀 들지 않습니다.

플래그에 대해: 구성 옵션(플래그에 추가로)이 있는 것이 더 낫다고 생각합니다. 나는 항상 깃발을 넘기고 싶지 않습니다. pip에 이 기능이 있는지 확실하지 않습니다. 더 영구적인 스위치를 원하는 사람들에게 해당 env var를 사용하라고 말씀해 주시겠습니까?

깃발에 관하여:

pip의 CLI 옵션은 적절한 이름으로 구성 파일 옵션 및 환경 변수에 자동으로 매핑됩니다.

@msarahan 시간 을 내주셔서 감사합니다. 감사합니다! :)

깨진 종속성을 무시하는 "내가 원하는 대로 하도록 하세요" 옵션과 관련하여 기본적으로 확인 프로그램이 켜진 후(예: 시작 --avoid-conflicts 를 옵트인으로 사용하면 결국 --no-avoid-conflicts 로 옵트아웃으로 이동하지만 처음부터 두 옵션을 모두 수락)

또한 --ignore-installed 가 솔버와 상호 작용하는 방식을 고려하고 싶을 것입니다. 솔버가 전달되면 이미 설치된 패키지에 대한 모든 요구 사항을 무시해야 합니다.

그 외에도 리졸버 통합을 더 쉽게 만들기 위해 더 작은 리팩토링 패치로 처리하는 것이 좋은 방법입니다.

@ncoghlan 해석기에서 "선택 해제"는 무엇을 의미합니까? 의존성 해결(따라서 리졸버)을 완전히 피하는 것은 --no-deps 입니다. "이 패키지에 대한 버전 충돌 무시" 또는 그와 관련된 내용이 필요하다는 것을 이해합니다.

개인적으로 저는 "최초 확인" 해결 논리를 새 해결 프로그램으로 전환하는 기간보다 오래 유지하는 것이 의미가 없다고 봅니다.

그러나 이 두 가지 옵션이 다루지 않는 사용 사례가 있다면 이에 대해 알고 싶습니다. :)

보다 광범위하게는 엄격한 리졸버의 동작에 문제가 있는 워크플로가 있는 경우 지원 여부/방법을 파악할 수 있도록 가능한 한 빨리 이러한 워크플로가 어떻게 보이는지 궁금합니다.

개인적으로 저는 "최초 확인" 해결 논리를 새 해결 프로그램으로 전환하는 기간보다 오래 유지하는 것이 의미가 없다고 봅니다.

IDK, 저는 이 "기능"을 사용하여 다음과 같은 빌드로 꽤 미친 작업을 수행합니다.

# install just the packages I've built specifically
pip install --no-index --no-deps --find-links=/path/to/my/local/build/cache -r local-reqs.txt

# ...snip to later in a dockerfile, etc...

# install the deps from public PyPI
pip install -r local-reqs.txt

이 경우 로컬 조타실에서 미리 결정된 패키지를 설치한 후 종속성을 해결하도록 요청합니다. 내 정확한 버전을 해당 local-reqs 파일로 읽어서 리졸버를 만족시킬 수 있다고 생각하지만 실제로 pip의 현재 동작은 이러한 종류의 임의 빌드 주입 단계를 허용하는 데 매우 유용하다는 것을 알았습니다. 하지만 스페이스바 난방 워크플로 의 경우일 수 있지만 인정하겠습니다.

그러나 아마도 "순진한 해결" 동작이 여전히 유용할 수 있습니다.

@pradyunsg님 말씀에 동의합니다. 기존 코드 와 새로운 리졸버를 무기한 유지하는 것은 불가능하다고 생각합니다. 확실히 pip 유지 관리자로서 나는 그런 일에 관심이 없습니다.

최종 사용자 POV에서 새 해석기가 올바른 작업을 수행하지 않을 수 있는 이상한 시나리오가 있을 수 있음을 인정합니다. 그리고 긴급 "이전 동작을 되돌려주세요" 플래그를 갖는 것은 중요한 전환 메커니즘입니다("이전 버전의 pip로 일시적으로 롤백" 여부는 논쟁의 여지가 있지만 CI를 일반적으로 사용하는 것과 같은 경우에도) 자동으로 해당 옵션을 옹호하는 최신 pip make를 사용합니다. 그러나 장기적으로 현재의 행동을 유지해야 하는 이유는 무엇입니까? 다음과 같은 주요 상황을 상상할 수 있습니다.

1. 리졸버 버그. 명백한 가능성, 쉬운 수정 - pip의 다음 릴리스에서 버그를 수정하십시오.
2. 이전 리졸버가 잘못된 경우(제약 조건을 충족하지 못하는 결과 생성). 우리는 앞으로 그것을 지원할 생각이 없습니까? (적어도 사용자가 원하는 것을 고정하고 --no-deps 를 사용하여 리졸버를 끄는 것보다 덜 극단적인 방법을 통해서는 아닙니다.)
3. 이전 리졸버와 새 리졸버가 서로 다른 결과를 제공하는 경우 둘 다 주어진 제약 조건을 충족합니다. 사용자는 이전 결과를 강제로 적용하기 위해 제약 조건을 추가할 수 있습니다(그렇지 않으면 (2)로 되돌아갑니다). 그렇게 할 시간을 주어야 하지만 다른 사용되지 않는 기능과 마찬가지로 이전 확인자를 삭제해야 합니다.
4. 지원하기에는 너무 복잡하거나 이상하다고 생각되는 극단적인 경우입니다. 이것은 (3)과 비슷하지만 새 해석기가 "올바른" 결과를 제공한다고 주장하지 않습니다. 사용자는 이상한 경우를 피하기 위해 제약 조건을 수정하거나 --no-deps 고정하고 사용할 수 있습니다. 그러나 궁극적으로 우리는 "하지 마십시오"라고 말하고 사용자가 해당 메시지를 무시하면 언젠가 다시 "경고했습니다"라는 이전 해결 프로그램을 제거합니다.

내가 놓친 다른 사람들이 있습니까? 특히 이전 리졸버를 더 이상 사용하지 않고 제거하는 것이 불가능한 곳은 어디입니까?

그건 그렇고, "여기에 내가 생각한 극단적 인 경우가 있습니다"시나리오를 게시하여 길을 잃지 않는 것이 가장 좋은 곳은 어디입니까? 테스트 케이스 작성을 조기에 시작할 수만 있다면 이상한 상황을 가능한 한 많이 수집하는 것이 유용할 것이라고 생각합니다 :-)

추신: 새로운 해석기를 위한 준비 작업의 일부로 "일반적인" 제약 조건 문제가 무엇인지 조사해야 합니다(PyPI에 있는 내용 기반). 내 자신의 경우 "pip install". 복잡한 경우에 너무 빠져서 대다수의 단순한 경우를 놓치는 것은 부끄러운 일입니다.

1. 리졸버가 너무 느립니다(conda 참조). 20분 이상의 리졸버 또는 현재 동작 중에서 선택해야 하는 경우 종종 현재 동작을 원합니다(또는 최소한 시도하십시오. 많은 경우에 좋은 결과를 얻을 수 있음).

2. 메타데이터가 잘못되었습니다. 오늘날에는 그다지 문제가 되지 않지만 해결할 수 있어야 하지만 해결되지 않는 경우를 쉽게 상상할 수 있습니다. PyPI 메타데이터는 conda/conda-forge 메타데이터보다 상태가 좋지 않으며 이미 conda에 문제가 있습니다. 그것이 틀렸고 사용자로서 솔루션을 얻을 수 없다면, 나는 약간의 옵트 아웃을 원할 것입니다.

@rgommers 6의 경우 "이 패키지의 버전 충돌 무시" 스타일 옵션이 작동할 수 있습니다.

감사합니다, @rgommers - 좋은 지적입니다.

리졸버가 너무 느립니다. 리졸버 버그로 간주하겠습니다. 단순한 경우에 충분한 성능의 결과를 제공할 수 없다면 그것은 내 생각에 목적에 적합하지 않습니다. 반면에 풀 리졸버로 시간이 더 오래 걸리는 엄청나게 복잡한 제약 네트워크가 있는 경우(20분이 과장되기를 바랍니다. 어떤 상황에서도 허용되지 않습니다!), 우리는 "우리가 지원하기에는 너무 복잡한 것으로 간주합니다." 다시 말해 "빠르고 더러운" 부정확하지만 빠른 해결자를 제공하도록 conda에 요청한 사람이 있습니까? 그들이 그렇게하지 않는다면 (그리고 나는 그들이하지 않을 것이라고 확신합니다) 왜 pip를 기대하는 것이 합리적입니까?

잘못된 메타데이터는 분명히 "지원하지 않을 것"이라고 생각합니다(여기서 "사용 중단 기간 이후"에 대해 이야기하고 있음을 기억하세요!). 사용자에게 메타데이터를 수정할 시간을 주고 "패키지 X에서 버전 충돌 무시" 이스케이프 절 옵션을 제공하는 것으로 충분합니다. 일부 사람들이 메타데이터를 수정하지 않는다고 해서 기존 기계를 모두 유지할 것으로 기대해서는 안 됩니다.

그러나 그렇습니다. 정확한 해석기가 "가비지 인, 가비지 아웃" 규칙을 따르기 때문에 좋은 메타데이터가 필요하다는 사실을 알리고 사람들이 해당 메시지에 어떻게 응답하는지 모니터링하는 것은 롤아웃 프로세스의 많은 부분입니다.

로컬 조타실에서 미리 결정된 패키지를 설치한 후 종속성을 해결하도록 요청하고 있습니다.

@jriddy "호환되는 경우 기존 설치 사용"의 해결 전략이 이에 대해 작동합니다.

"내가 생각한 극단적인 경우가 있습니다" 시나리오를 게시하여 길을 잃지 않도록 하는 가장 좋은 위치는 어디인가요?

https://github.com/pradyunsg/zazo/

6의 경우 "이 패키지의 버전 충돌 무시" 스타일 옵션이 작동할 수 있습니다.

예, 올바른 옵션처럼 들립니다.

(저는 20분이 과장되기를 바랍니다. 어떤 상황에서도 허용되지 않는다고 생각합니다!) 그러면 우리는 "지원하기에 너무 복잡하다고 생각하는 것" 영역에 들어가고 있습니다. 다시 말해 "빠르고 더러운" 부정확하지만 빠른 해결자를 제공하도록 conda에 요청한 사람이 있습니까? 그들이 그렇게하지 않는다면 (그리고 나는 그들이하지 않을 것이라고 확신합니다) 왜 pip를 기대하는 것이 합리적입니까?

conda 성능에 대해 불평하는 많은 사람들이 있고 그들은 듣고 있습니다. 그러나 그것은 많은 작업입니다. 그들의 최근 블로그 게시물을 참조하십시오. 빠르고 더러운 콘다 옵션이 있을지 모르겠습니다. 그러나 conda-metachannel 와 같은 관련 솔루션(해킹)이 있어 종속성 그래프를 정리(수동으로 패키지 포함/제외)하여 솔루션을 더 빨리 얻을 수 있습니다. 그래서 같은 맥락이라고 생각합니다.

그러나 다음 중 하나가 아닌 한 _확실히_ 필요합니다.

• 바로 conda보다 훨씬 더 나은 작업을 수행하십시오.
• 해결해야 할 문제는 더 작습니다(사실이 아니길 바랍니다. PyPI는 크고 좋은 메타데이터를 사용하면 문제가 커야 함)

잘못된 메타데이터는 분명히 "지원하지 않을 것"이라고 생각합니다.

그럴 수 있지. "올바른 메타데이터를 적용하지 않는다"는 전체적인 입장은 여기에서 도움이 되지 않습니다. 최근에 변경되지 않는 한? (그리고 나는 그것이 pip 것이 아니라 PyPI라는 것을 알고 있습니다. 그러나 그것은 관련이 있습니다).

나는 당신이 정말로 당신이 생각하는 옵션을 가지고 있는지 확신하지 못합니다.

빠르고 더티한 리졸버가 정확한 리졸버와 다른 점은 무엇입니까? 더 빠르기 위해 무엇을 떨어 뜨립니까? 제약 조건은 제약 조건입니다. 등급이 적용되지 않습니다. 당신은 그들을 만족하거나 그렇지 않습니다. 아마도 이름으로 시작하고 버전별로만 만족시킬 수 있습니다.

사람들이 Conda가 느려서 화를 내는 것은 본질적으로 항상 나쁜 메타데이터 때문입니다. 근본 원인에 관계없이 지각된 속도 저하에 대해 비난을 받을 것이라는 점을 명심하십시오. 잘못된 메타데이터는 때때로 잘못된 제약 조건이지만 훨씬 더 오래되고 바람직하지 않은 옵션을 고려할 수 있는 제약 조건이 없는 경우가 더 많습니다. Conda는 최근 한 가지 작은 일을 수행하여 크게 개선되었습니다. 즉, 부적절한(대부분 너무 개방된) 제약 조건이 있는 이전 소프트웨어 컬렉션을 제거하는 것입니다. 이러한 개방형 제약 조건으로 인해 conda는 많은 다운그레이드가 필요한 정말 나쁜 솔루션을 탐색하게 되었습니다. 여기서 문제를 해결하는 데 문자 그대로 몇 시간이 걸렸습니다. 다운그레이드는 캐스케이드 방식으로 인해 매우 비용이 많이 드는 작업이며, 각 단계는 제약이 덜하고 비용이 많이 듭니다.

"쓰레기 인, 가비지 아웃" 사고 방식의 문제는 해결사의 유지 관리인으로서 가방을 들고 있다는 것입니다. 쓰레기가 무엇인지에 대한 아주 좋은 경험적 방법이 없다면 당신은 무력합니다. 당신은 솔버가 느린 이유를 조사하고 문제 패키지를 분리한 다음 문제의 원인에 문제를 해결하도록 요청해야 하는 사람이 됩니다. 좋은 위치가 아닙니다. 저를 믿으세요. 우리는 conda가 conda-forge, bioconda 또는 기타 타사 채널을 혼합하여 사용하는 경우 또는 작동하지 않는 이유를 사람들에게 설명하는 데 많은 시간을 할애합니다. 결국 우리는 탐정 작업을 수행하고 해당 타사 채널에 수정해야 할 사항을 알려야 합니다. 짜증난다.

conda와 비교할 때는 conda가 문제에 대해 매우 다른 접근 방식을 취하고 있다는 점을 고려해야 합니다. Conda에는 하나의 거대한 메타데이터 소스가 있으며 모든 것을 한 번에 해결하지만 pip는 한 번에 각 항목을 재귀적으로 해결하고 최적화합니다(필요한 경우 역추적). 그것은 당신에게 다른 최적화 경로를 제공할 수 있습니다.

@wolfv 는 최근에 conda에 libsolv를 사용하여 탐색했습니다. 그는 궁극적으로 conda와 동일한 답변을 제공할 수 없다는 사실에 좌절했습니다. 이러한 접근 방식의 차이로 귀결되었습니다. Libsolv는 역추적 솔버입니다. 속도를 높이기 위해 pip에 대한 선택적 컴파일된 추가 기능으로 사용할 수 있지만 pip에 컴파일된 코드를 직접 포함하지 않는 것에 민감하다는 것을 알고 있습니다.

( @pradyunsg 는 자신의 블로그에 8월 업데이트를 게시했습니다 .)

사람들이 지금 제기하는 질문과 요구 사항 중 일부는 테스트 케이스와 같이 지금 수집을 시작해야 하는 것입니다.

그러나 또한: 이 롤아웃에 대해 현실적이라고 생각하는 일정은 무엇입니까? 이것은 Pradyun의 건강과 자유 시간, 다른 pip 유지 관리자의 코드 검토 가용성, 그리고 우리가 신청하는 보조금을 받는지 여부에 따라 많이 달라집니다. 하지만 순서는 다음과 같습니다.

• 빌드 로직 리팩터링: 진행 중, 12월-2월 중 완료
• UX 연구 및 디자인, 테스트 인프라 구축, 구성 플래그 및 전환 일정에 대해 다운스트림 및 사용자와 대화: 이를 위한 자금이 필요합니다. 가장 빠른 시작은 아마도 12월이며 2-3개월이 걸릴 것입니다.
• 알파 테스트를 수행하는 동안 resolvelib/zazo 에 정의된 추상화 도입: 몇 개월이 걸리므로 보수적으로 추정하면 2020년 5월입니까?
• 더 나은 종속성 해결을 채택하고 베타 테스트를 수행합니다.

이게 옳은 거니? 내가 무엇을 놓치고 있습니까?

정보 수집 작업 중 일부가 프로젝트 관리자 및/또는 UX 연구원이 해야 하는 일이기 때문에 질문합니다. 제 생각에는 https://github.com/pypa/packaging-problems/issues/264 및 다른 문제는 사람들이 여기에서 제기한 문제를 해결하는 데 도움이 될 수 있습니다.

잘못된 메타데이터는 때때로 잘못된 제약 조건이지만 훨씬 더 오래되고 바람직하지 않은 옵션을 고려할 수 있는 제약 조건이 없는 경우가 더 많습니다.

setup.py / pyproject.toml 에 대한 예외가 아니라 제약이 없는 종속성 또는 >= some_old_version 을 사용하는 것이 규칙이기 때문에 이것이 문제가 될 것입니다. 다른 선택을 해야 하는 "잘못된 제약 조건"이거나 솔버인지 여부는 별로 신경 쓰지 않습니다. 이것이 PyPI의 메타데이터 상태입니다.

이러한 개방형 제약 조건으로 인해 conda는 많은 다운그레이드가 필요한 정말 나쁜 솔루션을 탐색하게 되었습니다.

당신은 여기 전문가이지만 이에 대한 실용적인 해결책은 없습니까? 대부분의 경우 다운그레이드가 필요하지 않으므로 먼저 다운그레이드를 시도하십시오. 그런 다음 각 패키지에 대해 1개의 버전만 다운그레이드합니다. 추가로 다운그레이드해야 하는 경우 거의 항상 잘못된 솔루션입니다(나쁜 메타데이터 또는 다른 원인으로 인한 것일 수 있음).

사실 pip 가 다운그레이드를 _할 수 있는지_ 잘 모르겠습니다. 처음에는 너무 공격적인 "모든 것을 업그레이드" 전략을 사용했지만 이제는 "필요에 따라 업그레이드"가 꽤 잘 작동합니다. 나는 그것이 아무것도 다운그레이드하는 것을 본 적이 없으며 실제로는 정기적으로 사용하기에 꽤 잘 작동합니다.

conda가 경합해야 하지만 pip는 그렇지 않은 다운그레이드의 예: python 3을 사용하는 anaconda 또는 miniconda 사용자는 python 3.7부터 시작합니다. 사용자는 때때로 python 3.6에서만 사용할 수 있는 것을 설치해야 합니다. 솔버는 python 및 기타 모든 non-noarch 패키지를 다운그레이드해야 합니다. 이것은 아마도 파이썬 버전 변경에 대한 특별한 동작을 가짐으로써 최적화될 수 있는 특별한 경우이지만, 한 패키지의 변경이 다른 패키지로의 다운그레이드를 요구할 수 있는 요점을 보여줍니다. "지금까지 작동했습니다"는 실제로 항상 작동하는 것이 아니라 어리석은 행운입니다.

버전 제한에 관해서는 해결 자체에서 적용할 수 없습니다. 당신은 당신의 제약이 있고 모든 종류의 "하나의 버전으로 열기"는 모든 패키지마다 다르기 때문에 충분히 일반적이기를 바랄 수 없습니다. 하지만 솔버 이전에 버전별로 메타데이터를 잘라낼 수 있습니다. 이것이 conda의 "current_repodata.json"입니다. 최신 버전만. 작동하면 일이 정말 빨라지지만, 그것이 유일한 repodata라면 사람들은 정말 화를 낼 것입니다. 상황을 재현할 수 없으며, 언젠가는 작동하는 사양이 다음에는 작동하지 않을 수 있다는 사실에 좌절할 것입니다. 우리는 전체 repodata에 대한 대체를 제공하고 주어진 시점에 최신 버전만 사용할 수 있는 시간 기반 하위 집합을 도입할 계획입니다. 사용 가능한 인덱스 데이터를 점진적으로 여는 것이 역추적 솔버에서 더 유용한 개념일 수 있습니다.

pip 다운그레이드도 _할 수 있습니다.

-- pip의 경우 다운그레이드는 업그레이드와 같은 설치 제거 단계일 뿐입니다. 그리고 충족하도록 요청받은 제약 조건이 표시되면 다운그레이드됩니다.

다음은 pip가 가장 먼저 보는 한 setuptools를 다운그레이드합니다.

pip install "setuptools < 20.0"

"내가 생각한 극단적인 경우가 있습니다" 시나리오를 게시하여 길을 잃지 않도록 하는 가장 좋은 위치는 어디인가요?

https://github.com/pradyunsg/zazo/

감사합니다. 명심하겠습니다. 다시 생각해도 내 "병리학적 사례"는 실제로 그렇게 병리학적이지 않습니다. 패키지에 대한 종속성 메타데이터를 알기 위해서는 패키지를 다운로드하고 압축을 풀어야 하고 어떤 경우에는 많은 패키지를 다운로드하여 거부할 수 있다는 사실의 극단적인 경우입니다. 이는 우리가 해결해야 하는 "단순 색인" 프로토콜의 중요한 제한 사항일 수 있지만 직접적인 해결 문제는 아닙니다.

conda가 경합해야 하지만 pip는 그렇지 않은 다운그레이드의 예: python 3을 사용하는 anaconda 또는 miniconda 사용자는 python 3.7부터 시작합니다. 사용자는 때때로 python 3.6에서만 사용할 수 있는 것을 설치해야 합니다. 솔버는 python 및 기타 모든 non-noarch 패키지를 다운그레이드해야 합니다. 이것은 아마도 파이썬 버전 변경에 대한 특별한 동작을 가짐으로써 최적화될 수 있는 특별한 경우이지만, 한 패키지의 변경이 다른 패키지로의 다운그레이드를 요구할 수 있는 요점을 보여줍니다. "지금까지 작동했습니다"는 실제로 항상 작동하는 것이 아니라 어리석은 행운입니다.

또한 일반적으로 _다운그레이드하고 싶지 않은_ 경우입니다. 사용자로서 나는 패키지를 사용할 수 없다는 예외가 발생하고 내가 원하는 경우 명시적으로 3.6을 설치하도록 하고 싶습니다.

또 다른 예는 채널 간의 불일치입니다. 최근 예: 우리는 Python 3.7.3에 있었고 base 는 3.7.4 $를 받았습니다. 나는 이러한 버전 차이에 대해 신경 쓰지 않으며 대부분의 사용자는 신경 쓰지 않을 것입니다. 기본 "아무것도 하지 않음"이 " .4 > .3 , 업그레이드하고 필요한 경우 다른 패키지의 채널을 base 로 변경합시다(다운그레이드하더라도)"보다 훨씬 낫습니다.

우리는 전체 repodata에 대한 대체를 제공하고 주어진 시간에 최신 버전만 사용할 수 있는 시간 기반 하위 집합을 도입할 계획입니다.

그것은 매우 유용한 개선처럼 들립니다.

"쓰레기 인, 가비지 아웃" 사고 방식의 문제는 해결사의 유지 관리인으로서 가방을 들고 있다는 것입니다. 쓰레기가 무엇인지에 대한 아주 좋은 경험적 방법이 없다면 당신은 무력합니다.

네 사실이에요. 나는 모든 IDE, 배포판 또는 "많은 것들에 대한 공통 인터페이스"가 이 문제를 가지고 있다고 생각합니다.

다음은 setuptools 다운그레이드합니다.

사용자가 요청한 다운그레이드입니다. 간접적인 것은 내가 의미한 것입니다(예: setuptools<20.0 in pyproject.toml`). 그렇게 하면 잘 될 것 같지만 실제로는 드뭅니다.

"쓰레기 인, 가비지 아웃" 사고 방식의 문제는 해결사의 유지 관리인으로서 가방을 들고 있다는 것입니다.

100% 동의합니다. 아주 조심스럽게 다루어야 하는 일입니다. 그러나 반대로, 오래된 쓰레기에 대해 정상적인 행동을 시도하는 것은 실행 가능하지 않습니다. 우리는 어딘가에 선을 그어야 합니다.

참고로 이 논의는 기존 리졸버를 무기한 유지해야 하는지 여부에 대한 질문으로 시작되었습니다. 이러한 점 중 어느 것이 해당 질문에 실제로 영향을 미치는지 확실하지 않습니다. 기존 해결자가 옳지 않습니다. 사람들이 잘 알고 있는 고장난 행동이라고 말할 수 있습니다. 그래서 나는 위에서 말한 것을 지지합니다. 초기 전환 기간이 지난 후에도 이전 리졸버를 유지할 이유가 없습니다.

그리고 실제로 많은 사용 사례의 경우 이전 및 새 해석기가 어쨌든 동일한 결과를 제공할 것입니다.

"오른쪽"은 사용자가 변경 사항으로 인해 문제가 생겼을 때 중요하지 않습니다. 행동의 변화는 일부 사용자를 절대적으로 화나게 할 것입니다. 그들에게 그들의 작업 흐름이 잘못되었고 변화가 필요하다고 말하는 것은 나에게 그다지 효과적인 전략이 아니었습니다. 나는 당신이 그것을 귀로 연주해야한다고 생각합니다. 확실히 예전 리졸버를 영원히 유지하고 싶지는 않겠지만 사람들에게 유지 경로를 제공해야 할 것입니다. 예를 들어 다른 사람이 채택하고 유지 관리하는 플러그인을 만드는 것과 같이 사람들은 pip와 별도로 설치할 수 있습니다.

오래된 쓰레기에 대해 정상적인 행동을 하려고 노력하는 것은 실행 가능하지 않습니다. 우리는 어딘가에 선을 그어야 합니다.

예, 하지만 "오래된 쓰레기"는 무엇입니까? 무엇이 그것을 구별합니까? 나쁜 정크와 좋은 정크는 어떻습니까(새 것이 항상 더 좋은 것은 아니라는 점을 염두에 두십시오)? 내 조언은 솔버를 매우 디버깅할 수 있도록 만드는 데 많은 시간을 할애하는 것입니다. 전문가가 아닌 사용자가 잘못된 메타데이터가 문제인 경우와 해당 잘못된 메타데이터가 무엇인지 쉽게 식별할 수 있도록 상황이 어디로 가는지 쉽게 추적할 수 있습니다. 이것은 현재 대부분의 사용자에게 없는 기술이며 솔직히 내가 본 대부분의 사용자는 이 기술을 갖고 싶어하지 않습니다. 나는 당신(또는 그 문제에 대해서는 conda)이 나쁜 것과 좋은 것에 대해 완전히 정확한 자동 휴리스틱을 가질 수 없을 것이라고 생각합니다.

또한 일반적으로 다운그레이드를 원하지 않는 경우입니다. 사용자로서 나는 패키지를 사용할 수 없다는 예외가 발생하고 내가 원하는 경우 명시적으로 3.6을 설치하도록 하고 싶습니다.

@rgommers , conda 4.7이 여기로 이동했습니다. 마이너 버전을 변경하려면 명시적인 Python 사양이 필요합니다. 사람들은 그것을 싫어했습니다. 보컬이 몇 명인지는 모르겠지만 많은 사람들이 예전에는 conda install 를 할 수 있었다는 사실을 정말, 정말 싫어했지만 지금은 그렇게 할 수 없습니다. 그들은 그 이유에 대해 별로 신경을 쓰지 않고, 대답에 대부분 달래지만, 그 동안 우리는 여전히 처리해야 할 적대감을 가지고 있습니다. 의 또 다른 예

"오른쪽"은 사용자가 변경 사항으로 인해 문제가 생겼을 때 중요하지 않습니다.

또 다른 예는 채널 간의 불일치입니다. 최근 예: 우리는 Python 3.7.3에 있었고 base는 3.7.4를 얻었습니다. 나는 이러한 버전 차이에 대해 신경 쓰지 않으며 대부분의 사용자는 신경 쓰지 않을 것입니다. 기본 "아무것도 하지 않음"은 "이봐 .4 > .3, 업그레이드하고 필요한 경우 다른 패키지의 채널을 기본으로 변경합시다(다운그레이드하더라도)"보다 훨씬 낫습니다.

이것은 훨씬 더 복잡한 점입니다. 기본적으로 다른 최적화 기준을 제안하고 있습니다. https://www.anaconda.com/understanding-and-improving-condas-performance/ 의 블로그 게시물에서 현재 11단계를 보셨을 것입니다.

이것들은 매우 까다롭고 모든 상황을 만족시키는 전역 최적은 없습니다. 바이너리 호환성과 해당 호환성의 섬으로서의 채널을 감안할 때 채널의 강력한 우선 순위는 매우 중요합니다. 파이썬 빌드는 중요하지 않습니다. 당신 말이 옳습니다. 하지만 현재로서는 바이너리 호환성 제약 조건과 단순하고 단순한 버전 제약 조건을 표현할 방법이 없습니다. 그냥 내버려 두는 생각에 대해 생각하려면 이 정보가 필요합니다. 그렇지 않으면 빠르게 바이너리 비호환성 지옥에 빠지게 될 것입니다.

안녕하세요, 이 문제에서 저를 언급해 주신 @msarahan 에게 감사드립니다. 좀 더 일찍 연락하고 싶었지만 시간이 없었습니다.

실제로 libsolv 를 conda 사양에 대한 솔버로 사용하여 꽤 많은 실험을 했습니다. 그리고 그것은 작동 합니다. 이제 남은 차이점은 conda가 빌드 번호에 대해 별로 신경 쓰지 않지만 코딩된 방식(역추적 솔버 사용)이 libsolv에 있다는 것입니다. 전체 repodata를 사용하는 경우에도 libsolv는 정말 빠릅니다. libsolv의 속도는 짜증나지 않을 정도로 빠릅니다. :)

libsolv에 대한 나의 큰 공헌은 플랫폼 간 호환이 가능하여 이제 Windows, OS X 및 Linux에서 컴파일할 수 있도록 한 것입니다.

나는 그것이 컴파일된 코드의 덩어리(적어도 빠름)이고 @mlschroe 가 도움이 될 수 있음에도 불구하고 새 해석기에 대해 libsolv 를 사용하는 것을 전적으로 옹호합니다. 콘다 매치스펙.

반면에 리졸버 개발이 어느 단계에 있는지, 지금은 이미 너무 늦었는지, 컴파일된 코드가 허용 가능한지 여부가 확실하지 않습니다.

https://www.anaconda.com/understanding-and-improving-condas-performance/ 의 블로그 게시물에서 현재 11단계를 보셨을 것입니다.

실제로 나는 그랬다. 좋은 블로그 글이었습니다.

기본적으로 다른 최적화 기준을 제안하고 있습니다.

설마. 나는 당신의 _"이진 호환성 제약 대 평범하고 단순한 버전 제약"_이 아마도 내가 놓치고 있는 것을 가리킬 것이라고 생각합니다. 내가 예상하는 바는 어떤 패키지도 메타데이터에 python >= 3.7.4 또는 == 3.7.4 가 없어야 한다는 것입니다. 항상 == 3.7 입니다(scipy에 대해 확인했지만 meta.yaml 는 python 및 conda_forge.yml 는 max_py_ver: '37' 를 의미합니다. 따라서 3.7.4 를 도입하면 아무 것도 하지 않아야 합니다 3.7.3 를 선택하고 다른 것을 변경하지 않는 리졸버는 3.7.4 를 강제 실행하고 업/다운 등급의 체인.

pip 출시 계획에서 이 부분이 주제에서 벗어났을 것 같으니 이 부분을 다른 곳으로 가져가게 되어 기쁩니다.

내 조언은 솔버를 매우 디버깅할 수 있도록 만드는 데 많은 시간을 할애하는 것입니다.

+1

또한: 가능한 한 수리할 수 있도록 하십시오. 지금은 pip 의 좋은 점입니다. 일반적으로 문제가 발생하면 cd site-packages && rm -rf troublesome_package (아마도 --no-deps 를 사용한 재설치가 뒤따를 수 있음)를 수행할 수 있고 모든 것이 다시 작동합니다. conda , apt 및 친구와 같은 사람들은 그런 식으로 수리하기가 훨씬 어렵습니다.

기본적으로 다른 최적화 기준을 제안하고 있습니다.

나는 당신이 생각에 채널의 개념을 충분히 고려하고 있다고 생각하지 않습니다. 핍과 얼마나 관련이 있는지 모르겠습니다. 확실히 conda보다 훨씬 적지만 완전히 관련이 없는지 확실하지 않습니다. 사람들은 여전히 ​​한 번에 둘 이상의 인덱스에서 패키지를 수집할 수 있습니다. 그렇죠?

패키지에는 python >=3.7.4 또는 ==3.7.4가 없습니다. 콘다 패키징의 표준은 상한과 하한을 갖는 것입니다. 이는 일반적으로 호환 가능한 범위를 고려할 버전의 위치에 대해 레시피 작성자가 제공한 정보를 사용하여 conda-build에 의해 자동으로 결정됩니다. 패키지에는 >=3.7.2,<3.8.0a0과 같은 제약 조건이 있으며 시험판 ​​버전이 .0 릴리스 미만이고 따라서 사람들이 그렇지 않은 경우 <3.8.0 사양과 일치한다는 사실을 설명하기 위해 0a0 어색함이 있습니다. 정말 기대합니다.

패키지에는 연관된 채널도 있습니다. 이 채널은 효과적으로 버전 최적화의 일부입니다. https://github.com/conda/conda/blob/4.6.7/conda/resolve.py#L1074 - 채널은 슈퍼 버전과 같습니다. 패키지의 주요 버전. 해결이 python을 변경하지 않아야 하는 경우 python 사양은 python ==3.7일 수 없습니다. 즉, 범위이며 채널이 해당 범위에 영향을 미칩니다. 특히, python ==3.7 사양을 갖고 defaults 채널에서 설치를 시작한 다음 conda-forge 채널을 추가하면 많은 이탈이 발생합니다. "버전"(채널 포함)이 더 높고 Python 사양은 해당 변경 사항을 허용합니다.

Conda 4.7은 훨씬 더 공격적인 사양의 "고정"을 도입했으며 행동이 당신이 추구하는 것이라고 확신합니다. 하지만 꽤 복잡합니다. 명시적 사양과 충돌하지 않는 항목만 고정하는 것으로 요약됩니다. "충돌"을 결정하는 방법은 어려운 부분입니다. 우리는 솔버가 해당 패키지에 대한 종속성 그래프의 일부인 최신 패키지를 사용자에게 제공하는 것을 방해하는 것들을 동결하지 않는 것이 더 낫다고 생각합니다. 이 동결은 conda가 할 수 없는 방식으로 pip에 대해 사양별로 수행할 수 있기 때문에 언급할 가치가 있습니다. 역추적 솔버에 대한 훌륭한 최적화가 될 수 있다고 생각합니다.

또한: 가능한 한 수리할 수 있도록 하십시오. 그것은 지금 pip의 좋은 점입니다. 일반적으로 엉망인 경우 cd site-packages && rm -rf Troublesome_package(--no-deps로 재설치가 뒤따를 수 있음)를 수행할 수 있고 모든 것이 다시 작동합니다. conda, apt 및 친구와 같은 것은 그런 식으로 수리하기가 훨씬 어렵습니다.

예, 이것은 매우 중요합니다. 나는 pip가 그것을 깨뜨리기가 더 힘들도록 현명하게 판매하는 일을 잘했다고 생각합니다. 그것은 매우 현명하고 conda는 그로부터 배우고 있습니다. 컴파일된 코드를 사용하게 되면 정적으로 연결되어 있는지 확인하거나 동적 로딩이 문제를 일으킬 수 없는지 확인하십시오.

(libsolv tangent: RH에서 일할 때 https://pypi.org/project/solv/를 잡고 Fedora의 "pip install solv" 보안 허점을 닫았습니다. libsolv 빌드 프로세스는 현재 sdist 또는 wheel 아카이브, PyPI에 게시는 고사하고 지금과 같은 무해한 자리 표시자보다는 libsolv의 번들 사본으로 실제 라이브러리 바인딩을 만드는 데 관심이 있는 사람과 채팅하게 되어 기쁩니다)

내 "옵트아웃" 코멘트와 관련하여 "이전 설치 논리로 돌아가기"를 의미하는 것이 아니라 "전체 설치 요청을 실패하는 것보다 제약 조건 위반을 일으킬 수 있는 패키지 설치를 건너뛸 수 있는 옵션 제공"을 의미합니다.

Yum/DNF는 --skip-broken 옵션(DNF에서 해당 플래그는 --setopt=strict=0 의 별칭임)을 통해 이를 제공하며 pip 의 리졸버도 비슷한 옵션을 제공해야 한다고 생각합니다.

@ncoghlan 아 맞다. 그것은 의미가 있습니다.

"이 패키지의 버전 충돌 무시" 스타일 옵션

우리가 그렇게 할 것이라고 이미 언급했기 때문에 귀하의 의견이 혼란스러워졌습니다.

그때 우리는 같은 페이지에 있습니다. :)

@ncoghlan 은 distutils-sig 에서 내가 제안한 타임라인 에 답장했으며 합리적으로 들린다고 말했습니다.

@pradyunsg - 다음 월간 업데이트를 기대합니다!

나는 이것을 다시 한 번 살펴보고 #7317을 제출했다.

pip의 인덱스 상호 작용, 종속성 해결 + 빌드 논리 분리 및 일반적인 정리에 대한 많은 작업 덕분에 추상화에 거의 도달했다고 생각합니다.

방금 #7317을 닫았습니다. 내가 말할 수 있는 한, 종속성 해결은 이제 메타데이터 빌드 로직에서 (충분히) 분리되었습니다. 빌드 로직 리팩터링이 잘 진행되었으며 더 이상 진행을 방해하는 요소가 아닙니다.

이제 적절한 경우 [passa] 및 시의 리졸버 에서 참조를 사용하여 pip에서 [resolvelib] 추상화를 구현하는 작업을 시작할 수 있습니다. :)

@pradyunsg 저는 Poetry 코드베이스에서 base resolver(PubGrub 기반)를 추출할 계획입니다(https://github.com/sdispater/poetry/tree/master/poetry/mixology 참조). 대부분 나머지 코드와 분리되어 있지만 추상화해야 하는 내부 부분에 대한 참조가 여전히 있습니다.

도움이 필요하시면 저에게 알려주십시오. 아이디어는 타사에서 사용할 수 있는 PubGrub 알고리즘의 독립 실행형 구현을 갖는 것이며 현재 이전 리졸버의 코드를 보유하고 있는 https://pypi.org/project/mixology/ 에 포함될 것입니다.

@sdispater 확실히! 내가 직접 도울 수 있을지는 모르겠지만(시간 제약) 나머지 시에서 PubGrub 포트를 분리할 수 있다면 정말 좋을 것입니다!

정말 좋은 것 중 하나는 pip,시 및 pipenv가 동일한 추상화를 사용하도록 일관된 추상화 계층을 갖는 것입니다. 지금 우리는 zazo(광산), mixology(시) 및 resolvelib(pipenv's)를 가지고 있습니다. 모두 일종의 추상화 계층을 정의하고 약간 다르지만 (웃기게도!) 비슷합니다. 이 사실을 알고 계시다면 저희에게 알려주세요!

참고로, 우리( @wolfv 및 @QuantStack 팀 일반적으로)는 pip 종속성 해석기에 대한 RfP에 응답했습니다.

제안된 접근 방식은 libsolv C 라이브러리를 채택하고 pip의 버전 제한 형식에 대한 지원을 libsolv에 기여하는 것입니다. 우리는 새로운 파이썬 바인딩을 통해 C 라이브러리를 노출할 것입니다.

Libsolv는 RPM 생태계의 기반이 되는 강력한 라이브러리이므로 이미 산업 규모로 사용됩니다.

• Libsolv's는 BSD-3-Clause 라이선스에 따라 배포됩니다.
• Libsolv는 rpm , deb 와 같은 여러 패키지 및 저장소 형식을 지원합니다.
  haiku , conda , arch . 중요한 것은 다양한 형식과 표현 방식
  종속성 제약 조건은 다음을 수행할 수 있어야 하는 플러그형 시스템임을 보여줍니다.
  종속성 버전에 대한 제약 조건에 대한 pip의 구문을 수용하기 위해 ..
• 얇은 mamba 래퍼에서 conda의 솔버 대신 libsolv를 사용하여
  conda의 성능을 크게 향상시킬 수 있습니다. (큰 채널에서 conda의 느린 패키지 해상도는 mamba 작업에 대한 우리의 주요 동기였습니다).
• Windows, OS X 및 Linux에서 플랫폼 간 작동합니다. ( @wolfv 는 libsolv의 Windows 포트를 수행했습니다)
• 최적의 종속성 조합을 찾기 위해 전체 SAT 해결을 수행하고 성공하지 못하면 충돌 해결을 위해 실행 가능한 힌트를 반환합니다.

제안된 접근 방식은 libsolv C 라이브러리를 채택하는 것입니다.

libsolv가 지원하지 않는 플랫폼에 대한 대체가 필요합니다(예: pip의 AIX 지원이 활발하게 작업 중이고 BSD에 대해 언급하지 않았습니다). 따라서 libsolv를 사용 가능한 성능 옵션으로 사용하는 것이 그럴듯하지만 실제로 는 사용할 수 있는 위치에 있지 않습니다. (순수한 Python 버전의 libsolve가 있습니까, 즉 동일한 결과를 제공하지만 속도가 더 느릴까요?)

또한 get-pip.py는 어떻게 작동합니까? 가능한 모든 플랫폼에 대해 libsolv용 바이너리를 포함해야 합니까? 다시 말하지만, 우리는 순수 파이썬 폴백을 사용할 것이라고 가정합니다.

외부 C 코드를 사용할 수 없다는 것은 이제 오랫동안 pip에게 골칫거리였습니다. 나는 그것에 대한 좋은 솔루션을 보고 싶지만 (a) (우리가 완전히 벤더를 취소할 수 있게 해주는 "미니 핍" 부트스트래퍼 솔루션의 약어) 하나가 있는지 잘 모르겠습니다. (b) 새로운 리졸버가 그것에 의존하는 것을 싫어할 만큼 충분히 큰 작업입니다.

안녕하세요 @pfmoore

libsolv가 상당히 직관적인 C 코드이기 때문에 추가 플랫폼 지원을 달성하는 것이 그렇게 어렵지 않아야 한다고 생각합니다. 나는 libsolv의 순수한 Python 버전이 없다고 확신하지만(내가 이해하는 것은 단점이지만 Python의 순수한 Python 버전이나 Python 표준 lib도 없기 때문에 내 생각에는 차단제).

부트스트랩의 경우 현재 해결 메커니즘을 사용하는 순수한 Python pip가 있을 수 있다고 생각합니다. 그런 다음 libsolv를 기반으로 필요한 리졸버 lib를 설치합니다. 예를 들어 libsolv + pip 특정 Python 바인딩의 정확한 패키지를 고정하고 설명하는 대로 boosttrap-pip에서 설치할 수 있습니다. 그것은 나에게 완전히 할 수 있는 것처럼 들리지만, 관련된 것이 무엇인지 더 잘 알 수 있습니다 ...

추가 플랫폼 지원이 그렇게 어렵지 않아야 한다고 생각합니다.

분명히 말해서, 저는 더 많은 틈새 플랫폼에 기득권이 없습니다. pip가 지원되는 플랫폼(현재 기본적으로 "Python을 실행할 수 있는 모든 것")에 영향을 미치는지 매우 명확해야 한다고 생각합니다. ). C 확장을 제공하는 방법에 대한 배포 질문도 있습니다(pip는 현재 "범용" 휠로 제공되며 이는 get-pip.py 와 같은 일부 사용 사례에서 중요합니다).

부트스트래핑을 위해 현재 메커니즘을 사용하여 해결하는 순수한 Python pip를 가질 수 있다고 생각합니다.

나는 위에서 주장했고 여기서 반복할 것입니다. 나는 정말로 두 개의 리졸버를 pip에서 무기한으로 유지하고 싶지 않습니다.

하지만 제안에 대해 너무 부정적인 생각을 하고 싶지는 않습니다. 현재 C 확장에 대한 종속성을 인식하지 못하는 경우를 대비하여 현재 C 확장에 대한 종속성을 허용하지 않는 몇 가지 이유에 플래그를 지정하고 싶었을 뿐입니다.

토론은 아마도 다른 곳에서 더 적합할 것이며 더 자세한 내용이 공개되면 완전히 중복될 수 있지만 지금은 정말 제 질문을 하고 싶습니다.

내 이해에 따르면 libsolv는 종속성 해결을 위해 완전한 SAT 솔버를 사용하며 해결을 시작하기 전에 먼저 종속성 정보를 로드해야 합니다. 그러나 현재 PyPI는 패키지당 종속성 메타데이터를 저장합니다. setup.py 의 런타임 종속성을 무시하더라도 SAT 솔버에 필요한 정보를 효율적으로 가져오기가 어렵습니다.

이 문제를 어떻게 처리할 계획입니까? 패키지가 업로드될 때 .solv 파일을 생성하기 위해 인프라를 구현(및 타사 repo 구현을 위한 추가 사양 제안)할 계획입니까? 아니면 솔버가 진행되면서 적절한 해결 가능한 데이터를 생성하고 새로운 종속성 데이터가 들어올 때 일부 역추적을 구현하는 전략이 있습니까?

나는 이와 관련하여 기존 작업에 대해 알지 못하며 내가 찾을 수 있는 대부분의 리소스는 Python 패키징 환경에 직접적인 SAT 솔버 이상의 것이 필요하다고 제안합니다. 그래서 저는 여기에 있는 모든 가능성에 매우 관심이 있습니다.

이러한 .solv 파일은 캐싱용이며 libsolv는 해결을 위해 필요하지 않습니다. 그러나 PyPI 종속성의 동적 특성으로 인해 SAT 솔버를 사용하기 어렵다는 데 동의합니다.

(자세한 내용은 https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit 참조)

(참고로 SAT 솔버는 충돌이 발생하면 절 학습도 하는 역추적 솔버이므로 PyPI용 SAT 솔버를 사용할 수 있다고 생각합니다. 하지만 동적으로 절을 추가할 수 있는 솔버여야 합니다. 해결하면서.)

Sat 솔버는 요즘 동적 추가, 다시 시작, 역추적, 임의 다시 시작 등을 포함하여 몇 가지 중요한 기능을 가지고 있습니다. 그러나 여기서 문제는 부분적으로 빌드할 수 있다는 보장이 없는 플랫폼을 지원해야 할 필요성과 관련된 기술적인 문제가 될 것이라고 생각합니다. C 기반 솔버.

저는 지금 공항에 있기 때문에 지금 제기된 요점에 답할 수 없지만... 여기서 기술적인 선택/상충 관계에 대해 논의해서는 안 된다고 확신합니다. 롤아웃과 롤아웃의 커뮤니케이션 및 관리 방법. :)

@sdispater , @techalchemy , @uranusjr , @wolfv - 기술적 절충점에 대한 추가 논의를 위해 #7406을 제출했습니다. 리졸버 설계를 위한 다양한 선택에 대해 추가 논의가 가능하면 감사하겠습니다.

조기에 기대치를 설정하기 위해 앞으로 2주 동안 여행할 예정이며 ~12월 9일에 있을 모든 토론을 따라잡을 수 있기를 바랍니다.

상태 업데이트: PSF는 Mozilla Open Source Support 및 Chan Zuckerberg Initiative로부터 핍 리졸버 및 관련 사용자 경험 문제에 대해 작업할 계약자를 고용하기 위해 일부 자금을 확보할 수 있었습니다 . 우리의 로드맵 (정리해야 함)과 블로그, 포럼, 메일링 리스트 게시물과 최근 회의의 메모를 볼 수 있습니다. 이에 대해 곧 distutils-sig 및 Python의 Discourse 인스턴스에 대한 Packaging 포럼에 게시할 예정입니다.

우리는 7월에 pip 20.2 릴리스를 위해 pip의 리졸버 기능을 준비하는 것을 목표로 합니다. (pip의 분기별 릴리스 케이던스에 따라 예상치 못한 어려움이 다음 분기의 20.3까지 지연될 수 있습니다.)

@uranusjr :

내 이해에 따르면 libsolv는 종속성 해결을 위해 완전한 SAT 솔버를 사용하며 해결을 시작하기 전에 먼저 종속성 정보를 로드해야 합니다. 그러나 현재 PyPI는 패키지당 종속성 메타데이터를 저장합니다. setup.py의 런타임 종속성을 무시하더라도 SAT 솔버에 필요한 정보를 효율적으로 가져오기가 어렵습니다.

#7819의 프로토타입 pip resolve 명령은 두 가지 기술을 사용하여 이 정보를 효율적으로 가져옵니다(자세한 내용은 해당 문제 참조).

1. > 휠을 실제로 다운로드하지 않고 휠의 URL에서 METADATA 파일의 내용을 추출합니다.
2. > 각 self._resolve_one() 호출의 결과를 영구 json 파일에 캐싱합니다.

(1)에 사용된 기술은 휠 콘텐츠 자체의 몇 KB만 다운로드하면서 휠 URL을 매우 빠르게 의존하는 요구 사항 문자열 목록으로 변환할 수 있습니다. 그런 다음 #7819의 프로토타입은 self._resolve_one() 에서 반환된 각 종속 요구 사항에 대해 req.populate_link() 이 호출되고 영구 json 캐시 파일에 (==Requirement, url) -> [list of (==Requirement, url) non-transitive dependencies] 매핑을 저장합니다. (1) 새로운 정보를 빠르게 얻고, (2) 오래된 정보를 빠르게 쿼리합니다.

나는 아직 libsolv에 익숙하지 않지만 요구 사항 URL에서 종속성 및 해당 URL로의 매핑 항목이 SAT 솔버에 필요한 원자적 입력과 정확히 일치할 수 있다고 생각합니다. #7189에 설명된 대로 영구 json 종속성 캐시 파일로 인해 첫 번째 실행 후 pip resolve 호출이 명령줄에서 800-900ms가 걸리며 완전한 무작동이 되었습니다. (1)과 (2)의 기술을 사용하면 엄청나게 오랜 시간을 기다리지 않고 pip가 호출될 때마다 SAT 솔버가 완료될 때까지 실행할 수 있다고 생각합니다. 이 숫자를 더 구체적으로 만들기 위해 #7189의 프로토타입 위에 libsolv를 해킹하는 것은 그리 어렵지 않을 것입니다.

@techalchemy :

Sat 솔버는 요즘 동적 추가, 다시 시작, 역추적, 임의 다시 시작 등을 포함하여 몇 가지 중요한 기능을 가지고 있습니다. 그러나 여기서 문제는 부분적으로 빌드할 수 있다는 보장이 없는 플랫폼을 지원해야 할 필요성과 관련된 기술적인 문제가 될 것이라고 생각합니다. C 기반 솔버.

바지 에는 컴파일러와 링커를 setup.py 기반 프로젝트에 더 쉽게 노출할 수 있는 코드가 있었지만(#6273) 나중에 빌드를 가능하게 하기 위해 이것을 제거했습니다(#7016 참조). setup.py 를 사용하지 않고 바지에 C/C++ . 이는 TensorFlow 사용자 정의 연산자 를 위한 공유 라이브러리를 구축하기만 하면 되는 Twitter 내부의 사용 사례에 적합했습니다. 우리는 OSX 및 Linux용 s3(https://github.com/pantsbuild/binaries/ 참조)에서 정적으로 연결된 GCC 및 binutils 아카이브용으로 사전 빌드된 바이너리를 호스팅하므로 바지 사용자는 Python 및 JDK 외에는 아무것도 설치할 필요가 없습니다. 바지를 전혀 사용하지 마십시오.

지원되는 모든 플랫폼에서 pip가 libsolv에 안정적으로 의존할 수 있도록 C 및 C++를 이식 가능하게 빌드하기 위한 모든 유형의 도구를 브레인스토밍 및/또는 개발하는 데 도움이 되고 싶습니다.

@cosmicexplorer

바지에는 컴파일러와 링커를 setup.py 기반 프로젝트(#6273)에 더 쉽게 노출할 수 있는 코드가 있었지만 나중에 C/C++ 빌드를 가능하게 하기 위해 이것을 제거했습니다(#7016 참조). TensorFlow 사용자 정의 연산자를 위한 공유 라이브러리를 구축하기만 하면 되는 Twitter 내부의 사용 사례에 적합한 setup.py를 사용하지 않고 바지에. 우리는 정적으로 연결된 GCC 및 binutils 아카이브용으로 미리 빌드된 바이너리를 OSX 및 Linux용 s3에 호스팅하므로(pantbuild/binaries 참조) 바지 사용자가 바지를 사용하기 위해 Python과 JDK 외에 아무것도 설치할 필요가 없습니다.

컴파일러/링커 작업은 매우 흥미롭습니다! 컴파일러를 setup.py(또는 일반적으로 PEP 517 빌드 백엔드)에서 분리하는 방법에 대한 논의도 있습니다. 리졸버와 실제로 관련이 없지만(적어도 직접적으로는 아님) 관심이 있을 수 있습니다. https://discuss.python.org/t/how-do-we-get-out-of-the-business-of- driving-c-컴파일러/2591

@cosmicexplorer

지원되는 모든 플랫폼에서 pip가 libsolv에 안정적으로 의존할 수 있도록 C 및 C++를 이식 가능하게 빌드하기 위한 모든 유형의 도구를 브레인스토밍 및/또는 개발하는 데 도움이 되고 싶습니다.

저와 @wolfv 는 맘바 를 위한 모든 주요 지원 플랫폼에서 DNF 패키지 관리자 스택의 일부를 구축하고 DNF에 대한 제 개인적인 작업을 위해 이것을 살펴보고 있습니다. 이 시점에서 libsolv는 이제 Windows, Linux, macOS, BSD, Haiku OS용으로 빌드할 수 있으며 UNIX에서 DNF 를 사용하는 일부로 다양한 UNIX 시스템에 배치된다는 것을 막연하게 알고 있습니다. @dralley 가 solv 바이너리 휠을 PyPI에서 manylinux2014 를 사용하여 PyPI가 지원하는 ~주요 플랫폼에서 사용할 수 있도록 만들었다는 것도 알고 있습니다.

이제 새로운 리졸버의 초기(알파) 버전이 포함된 베타 릴리스인 pip 20.1b1이 출시되었습니다(관련 내용은 #8099 및 사람들이 피드백을 제공할 수 있는 설문조사 참조). 여기 발표가 있습니다. 그리고 https://github.com/pypa/pip/issues/7951#issuecomment -617851381 에는 지금까지 베타를 공개한 장소가 나열되어 있습니다.

pip 20.1이 출시되었으며 리졸버의 알파 버전이 포함되어 있습니다.

우리는 5월에 또 다른 pip 릴리스를 게시하는 것에 대해 논의하고 있습니다. 여기에는 해결 프로그램의 추가 알파가 포함되어 있습니다. 그리고 우리는 언제 새로운 리졸버의 베타를 출시할 것인지 파악하고 "이것을 테스트해 주세요" 푸시를 할 것입니다.

우리는 #8371, 특정 오류 메시지를 더 잘 표시하는 방법, 기타 많은 것들을 처리하는 동안 지연에 부딪쳤습니다. 진행 상황에 대한 자세한 내용은 https://github.com/pypa/pip/projects/6 및 https://github.com/pypa/pip/projects/5 를 참조하세요. #8206은 곧 출시될 베타인 pip 20.2b2에 대한 토론으로, 6월 말까지 게시할 수 있기를 바랍니다.

PSF 블로그 에 중간 보고서 를 게시 했습니다 . 알아야 할 한 가지 핵심 사항: 이번 달 말 에 선택적 플래그 " --use-feature=2020-resolver "를 통해 사용할 수 있는 새 종속성 해결기의 베타 버전(pip 20.1에는 알파 버전이 있음)이 있는 pip 20.2를 출시할 예정입니다. 우리는 pip 20.2를 많이 공개하고 많은 사용자에게 새로운 리졸버를 사용하도록 요청할 것입니다.

#8511에 따라 우리는 이제 pip 20.2 를 출시했습니다. 이 릴리스에는 차세대 종속성 해석기의 베타가 포함되어 있습니다. 호환되지 않는 지침을 받을 때 훨씬 더 엄격하고 일관성이 있으며 특정 종류의 제약 조건 파일에 대한 지원이 감소하므로 일부 해결 방법 및 워크플로가 중단될 수 있습니다. --use-feature=2020-resolver 플래그로 테스트하십시오 . 테스트 및 마이그레이션 방법과 문제 보고 방법에 대한 가이드를 참조하세요. 새 종속성 분석기는 아직 일상적으로 사용할 준비 가 되지 않았기 때문에 기본적으로 꺼져 있습니다.

우리는 2020년 10월에 pip의 다음 분기별 릴리스인 20.3을 만들 계획입니다. 우리는 기본 종속성 해결 동작을 변경하고 pip 20.3에서 새 확인자를 기본값으로 만들 준비를 하고 있습니다.

Hacker News, Reddit, Twitter, Facebook, Dev.to, Telegram, 관련 스택 오버플로 답변, 좋아하는 Slacks 및 Discords 에 이 블로그 게시물 을 가리켜 널리 알리십시오. 이것이 영향을 미칠 대부분의 사람들은 Python 관련 개발자 뉴스를 따라가지 않습니다. 10월 이전에 미리 알림을 받고 버그 보고서를 받을 수 있도록 도와주세요.

(#988에서 내 메모를 복사합니다.)

@zooba 는 다음과 같이 질문했습니다 .

이 단계(첫 번째 RC의 경우)에서 Python 3.9와 함께 번들로 제공되는 pip 버전을 업데이트해야 한다고 생각하십니까?

마찬가지로 다음 릴리스를 위해 Python 3.8을 업데이트해야 합니까?

내 가정은 네, 다음 주 초에 버그 수정이 릴리스된 후 네, 하지만 @pfmoore @xavfernandez @cjerdonek @uranusjr @pradyunsg @dstufft 어떻게 생각하세요?

죄송합니다. 너무 빨리 게시를 누르십시오. 내 추론은 pip 20.2를 번들로 제공하면 노련한 개발자가 최신 버전의 Python을 테스트하면서 새로운 종속성 해결 프로그램을 훨씬 쉽게 테스트할 수 있다는 것입니다. 하지만 번들 버전을 업데이트하는 데 얼마나 많은 작업이 필요한지 또는 얼마나 자주 업데이트하고 싶은지 모르겠습니다.

여기에서도 마찬가지로 새 해석기에 더 쉽게 액세스할 수 있도록 3.9에 20.2.x를 포함하는 것이 좋습니다.

어떻게 생각해?

당신이 맞습니다, 그것이 계획입니다. :)

OK, python-dev에 대한 답변 -- 예, Python 3.8 및 3.9에 번들로 제공되는 pip 버전은 20.2.x로 업데이트되어야 합니다.

이와 별도로 홍보를 위해 진행 중인 몇 가지 작업에 대해 언급하겠습니다.

앞으로 6-8주 동안 사용자가 새로운 pip을 사용해 볼 수 있도록 널리 홍보할 것입니다. 나는 문제가 "이 개별 패키지가 설치되지 않을 것"이라고 생각하지 않습니다. 환경 및 특정 제약 조건 파일에 따라 특정 패키지 간에 예기치 않은 충돌이 발생할 수 있습니다. 우리는 설문조사 를 통해 초기 피드백을 받고 버그를 수정하고 더 많은 자동화된 테스트 등을 설정할 수 있도록 하고 이러한 업스트림 패키지가 pip 20.3(예제 : https://github.com/pypa/pip/issues/8076#issuecomment-666493069의 TensorFlow/numpy/scipy 문제).

우리가 이것에 얼마나 많은 노력을 들이든 간에 20.3에 걸려 넘어지는 불일치를 처리하는 사용자가 있을 것이며 좌절하고 혼란스럽고 상처를 입을 것이며 이는 우리와 모든 업스트림에 대한 지원 부담을 야기할 것입니다. 우리는 사용자가 테스트하고 업스트림의 관심을 끌도록 하여 이를 줄이는 것을 목표로 합니다.

그래서 저는 데이터 과학자, 교사, 아티스트, DevOps 전문가 등 자신의 특정 영역별 코너에 관심을 기울이는 그룹에 연락하고 활용할 계획입니다.

나는 그들의 관심을 끌 수 있는 한 가지 방법이 그들이 의존하는 특정 패키지를 통하는 것이라고 가정합니다.

어제 저는 널리 사용되는 패키지 목록을 살펴보고 몇 사람에게 수동으로 이메일을 보냈고 몇 리포지토리에 문제를 만들어 사용자에게 새 해결 프로그램의 베타로 테스트하고 공을 굴리기 시작하고 일부를 사용해 보라고 제안했습니다. 더 많은 홍보 및 테스트를 위한 문구/접근법. 이로 인해 적어도 한 가지 경우에 혼란이 야기되었습니다. https://github.com/sqlalchemy/mako/issues/322#issuecomment-667546739를 참조하십시오. 그리고 20.2의 버그 수정 릴리스가 나오면 조금 더 에 대해 체계적이고 명확하게

• 우리가 연락하는 이유
• 연락하기로 선택한 사람/시기(공개 미디어 전략에 연결하면 도움이 됨)
• 자동 테스트를 사용하여 이러한 문제를 스스로 찾을 수 없는 이유

우리는 Twitter( 1 , 2 ) 및 Reddit ( PyPA 자금 조달에 대한 이 질문에 답하고 싶은 사람이 있습니까?)에서 약간의 관심을 받았습니다.

@zooba 는 (번들링과 관련하여) 다음과 같이 썼습니다.

감사 해요. 이번 주 후반에 할 수 있고 다음 릴리스를 만들 수 있을 것 같습니다. 석방되고 싶지 않은 일이 발생하면 최대한 빨리 알려주십시오.

--use-feature=2020-resolver 는 일반적으로 원인보다 더 많은 문제를 해결합니다.

다음을 통해 초기 출시를 제안하기에는 너무 늦었습니까?

제안된 20.3 의사 코드

try:
    _2020_resolver()
except:
    legacy_resolver()

이는 적어도 내 프로젝트의 경우 수정 없이 모두 통과할 것임을 의미합니다.

그 후 레거시 리졸버가 기본적으로 비활성화되면 잠시 동안 2020-resolver에서 작동하는 일부 프로젝트와 legacy-resolver에서 작동하지 않는 프로젝트가 있을 수 있습니다. 하나의 플래그를 설정하여 폴백을 활성화할 수 있기를 바랍니다.

제안된 20.4 의사 코드

try:
    _2020_resolver()
except:
    if not use_legacy_resolver:
        raise
    legacy_resolver()

이번 달 말에 20.3을 출시할 계획입니다. 혼란스러운 사용자가 질문을 하기 때문에 많은 사용자 지원이 필요할 것으로 예상합니다.

@di 는 첫 번째 응답을 돕기 위해 일부 자원 봉사자를 모으는 데 자원했습니다. 이 자원 봉사자는 Twitter, StackOverflow 및 GitHub에서 새 pip가 나오면 질문에 답변하고 사용자 지원 부하를 도우며 실제 버그를 유지 관리자/기여자 팀의 주의로 에스컬레이션합니다.

Dustin, 어떻게 작동할지에 대한 대략적인 계획이 있다고 생각합니다. 여기에 게시하면 다른 pip 유지 관리자로부터 합의를 얻을 수 있습니까? 감사합니다.

내 대략적인 계획은 다음과 같습니다.

• 지원을 요청하는 토론을 시작하십시오.
• 모든 사람 간의 커뮤니케이션 채널 역할을 할 수 있는 Slack 채널로 사람들을 안내합니다.
• 몇 가지 FAQ 및 답변을 요약한 문서 시작
• 새 문제에 대한 의사 결정 트리 포함 -> 분류된 문제
• 출시일이 알려지면 이를 채널과 공유하세요.
• 자원 봉사자가 온라인 상태가 되도록 대략적인 일정을 계획하고 릴리스 다음 날에 분류합니다.

@di님 감사합니다. 우리는 다른 관리자들로부터 승인을 받기 위해 내일까지 기다리고 있습니다. 그리고 우리는 10월 28일이나 29일 수요일이나 목요일에 pip 20.3을 출시하는 것을 목표로 하고 있습니다.

@di 귀하의 계획이 승인되었음을 확인했습니다. 진행하시기 바랍니다!

@di 는 릴리스 지연 가능성 에 대해 경고합니다.

20.3(다음 주에 출시될 예정)을 게시할 수 있을 때 제가 참석할 수 없는 경우를 대비 하여 홍보 계획이 있습니다.

다른 곳의 의견에서 논의한 것처럼 일부 CI 문제가 발생하고 일부 외부 요인으로 인해 릴리스를 약간 연기하기로 결정했습니다.

오늘 팀 회의에서 우리는 20.3 릴리스가 내일이나 금요일에 있을 것이라는 데 동의했습니다. 자세한 내용은 #8936을 팔로우하세요.

이전 의견에서 제안한 것만큼 패키지별 홍보 활동을 많이 하지 않았습니다. 하지만 그렇다고 해서 우리가 홍보를 하지 않은 것은 아닙니다. 우리가 수행한 봉사 활동 중 일부(일부는 #8511 또는 이 위키 페이지 에 카탈로그되어 있음):

• 팟캐스트: Podcast.__init__ , 테스트 및 코드 , FLOSS Weekly , 소프트웨어 개발자 여정 , Real Python
• 많은 트윗
• 변경 사항에 대한 짧은 YouTube 동영상
• PSF 후원 담당자가 PyCon, PSF 및 PyPI 후원자에게 이메일을 보내 향후 변경 사항에 대해 엔지니어링 부서에 알리도록 요청합니다.
• pypi-announce 및 이와 유사한 목록에 대한 이메일
• 이와 같은 블로그 게시물
• 시민 기술 및 유사 그룹/싱크 탱크에 이메일

지난 몇 달 동안 우리는 20.2 및 20.3 베타, pip 20.3b1 에서 새로운 리졸버를 테스트하는 사람들로부터 새로운 문제를 꾸준히 받아왔습니다. 이러한 보고서는 리졸버를 개선하고 버그를 수정하며 출력의 UX를 개선하는 데 도움이 되었습니다. 또한 부분적으로 베타 피드백에 대한 응답으로 "변경 사항" 사용자 가이드를 크게 개선했습니다 .

내 대략적인 계획은 다음과 같습니다.

* Start a discussion on discuss.python.org asking for support

* Direct folks to a Slack channel that could serve as a communication channel between everyone

* Start a document outlining some FAQ and our responses

* Include a decision tree for new issue -> triaged issue

* Share this with the channel once we have a known release date

* Try and roughly schedule volunteers to be online & triaging in the days following the release

@di 지속적인 불확실성과 지연으로 인해 일정을 수행할 수 없다는 것을 알고 있습니다. 새 릴리스 날짜는 내일, 11월 30일 월요일입니다. 이제 공유할 토론 스레드와 의사 결정 트리가 있다면 계속해서 공유하십시오!

pip 20.3이 출시되었으며 기본적으로 새 해석기가 있습니다! 다음은 PSF 블로그의 릴리스 발표입니다. https://blog.python.org/2020/11/pip-20-3-release-new-resolver.html