문제 해결 가이드

이 가이드의 단계를 따라 가장 일반적인 파이썬 환경 생성 문제를 디버깅하십시오:

• 문제 해결 가이드
  • 패키지 해결 중 검사 실패
    • 새로운 Mamba 오류 메시지
      • 의존성 트리
      • 직접적인 충돌
      • 직접적인 의존성 충돌
      • 전이적 의존성 충돌
      • 새로운 오류 메시지 해석
    • 레거시 Mamba 오류 메시지
      • 패키지 찾을 수 없음
      • 의존성 찾을 수 없음
      • 중복 패키지 오류
      • 권한 오류 디버깅
      • 패키지 충돌
        • 패키지 충돌 디버깅
        • 버전을 고정하지 않아도 해결 실패를 고치지 않는 이유는?
      • 요청된 패키지의 변경 없이 실패
  • meta.yml에 변동이 없는 경우 느려짐 디버깅
  • meta.yml에 변동이 있는 경우 작업이 시간 초과
  • Conda 오류와 함께 빌드 실패
    • 멀티 다운로드 실패
  • 엔트리 포인트 오류와 함께 빌드 실패
  • Conda 패키지와 JAR 둘 다 필요한 패키지
  • 의존성 충돌을 피하기 위한 모범 사례
    • 의존성 충돌을 피하기 위한 모범 사례: 파이썬
      • 파이썬 버전 지원
    • 의존성 충돌을 피하기 위한 모범 사례: 파이썬 이외의 패키지
  • 기타 문제

패키지 해결 중 검사 실패

다음 검사 실패의 경우, 코드 레포지토리 내 '검사' 탭에서 검사 로그를 확인할 수 있습니다. 이 로그를 사용하여 검사가 실패한 이유를 알아낼 수 있습니다.

새로운 Mamba 오류 메시지

Palantir은 환경 초기화 오류 메시지의 더 나은 형식을 제공하여 오픈 소스 Mamba 커뮤니티에 기여하였습니다. 2023년 2월부터 Foundry 서비스는 환경 실패로 인한 의존성 트리를 더욱 잘 표현하는 오류에서 이익을 얻습니다.

의존성 트리

다음 예제에서:

packageA
   ├─ packageB // 패키지 B
   └─ packageC // 패키지 C
        └─ packageD // 패키지 D

packageB와 packageC는 packageA의 직접 종속성입니다. packageD는 packageC의 직접 종속성이지만 packageA의 전이적 종속성입니다. packageA는 packageD에 대한 직접 제약조건을 가지고 있지 않지만, packageA의 packageC에 대한 직접 요구사항이 간접적으로 packageD에 제약조건을 강요합니다. 아래에 그러한 개념의 실제 예시를 찾을 수 있습니다:

Copied!
1
2
3
4
5
6
7
8
9
statsmodels  <!-- 통계 모델을 분석하고 테스트하는데 사용하는 Python 라이브러리 -->
├─ numpy  <!-- 수치 계산을 위한 Python 라이브러리 -->
├─ scipy  <!-- 과학 계산을 위한 Python 라이브러리 -->
├─ matplotlib  <!-- 데이터 시각화를 위한 Python 라이브러리 -->
│  │  ├─ libpng  <!-- PNG 이미지를 읽고 쓰는데 사용되는 라이브러리 -->
│  │  ├─ setuptools  <!-- Python 패키지 관리를 위한 라이브러리 -->
│  │  ├─ cycler  <!-- 그래프의 색상, 선 두께 등을 순환하여 변경하는데 사용되는 라이브러리 -->
│  │  ├─ dateutil  <!-- 날짜와 시간을 조작하는데 사용되는 라이브러리 -->
│  │  └─ kiwisolver  <!-- 제약조건을 기반으로 레이아웃을 계산하는데 사용되는 라이브러리 -->

statsmodels가 libpng에 제약을 가하고 있다는 것이 처음에는 명확하지 않을 수 있지만, matplotlib에 대한 제약을 통해 간접적으로 제약을 가하고 있습니다.

직접 충돌

직접 충돌은 동일한 환경에서 동일한 패키지의 다른 버전이 요청될 때 발생합니다. 간단한 환경에서 python 3.7과 python 3.8을 모두 요청한다고 상상해보세요. 이것은 환경에 실패를 일으키는 직접 충돌입니다. 새로운 오류 메시지는 다음 정보를 제공할 것입니다:

  환경 스펙을 해결할 수 없음
  다음 패키지들은 호환되지 않음
  ├─ 요청된 Python 3.7** 은 설치 가능;
  └─ Python 3.8** 은 이전에 보고된 설치 가능한 버전과 충돌하여 제거할 수 없음.

위 메시지는 python 3.7이 실제로 설치될 수 있음을 올바르게 설명하고 있습니다. 그러나 해당 버전이 설치된 경우, 추가적인 다른 버전을 설치하려는 시도는 충돌을 일으킬 것입니다. 이 환경은 환경에서 파이썬의 두 버전 제약 중 하나를 제거하여 해결할 수 있습니다.

그러나 직접적인 충돌은 의존성과 전이 의존성에 의해 생성된 충돌에 비해 매우 드물다고 할 수 있습니다.

직접 의존성 충돌

NumPy 문서에서는 numpy >=1.22.0이 python >=3.8을 필요로 한다고 명시적으로 언급하고 있습니다. 따라서 python 3.7.*과 numpy 1.22.0을 모두 요청하는 환경을 만들려고 하면 직접 의존성 충돌이 발생할 것입니다. 다음 오류 메시지가 발생할 것입니다:

환경 사양을 해결할 수 없음
다음 패키지들이 호환되지 않음
├─ numpy 1.22.0**  설치 가능한 옵션들과 함께 설치 가능
│  ├─ numpy 1.22.0 이 필요한 경우
│  │  ├─ python >=3.9,<3.10.0a0 , 설치 가능;
│  │  └─ python_abi 3.9.* *_cp39, 설치 가능;
│  ├─ numpy 1.22.0 이 필요한 경우
│  │  ├─ python >=3.10,<3.11.0a0 , 설치 가능;
│  │  └─ python_abi 3.10.* *_cp310, 설치 가능;
│  └─ numpy 1.22.0 이 필요한 경우
│     ├─ python >=3.8,<3.9.0a0 , 설치 가능;
│     └─ python_abi 3.8.* *_cp38, 설치 가능;
└─ python 3.7**  가능한 옵션이 없기 때문에 설치할 수 없음
   ├─ python [3.7.10|3.7.11|...|3.7.9] 이전에 보고된 설치 가능한 버전과 충돌;
   ├─ python [3.7.0|3.7.1|3.7.2|3.7.3|3.7.6] 이 필요한 경우
   │  └─ python_abi * *_cp37m, 이전에 보고된 설치 가능한 버전과 충돌;
   └─ python [3.7.10|3.7.12|...|3.7.9] 이 필요한 경우
      └─ python_abi 3.7.* *_cp37m, 이전에 보고된 설치 가능한 버전과 충돌.

이 오류 메시지는 numpy 1.22.0이 Python 3.8, 3.9 또는 3.10과 함께 설치 가능하지만 요청된 3.7.* 버전과 충돌한다는 것을 알려줍니다. 이 환경은 Python 또는 NumPy의 제약 조건을 완화함으로써 해결할 수 있습니다. 예를 들어, python 3.8.*과 numpy 1.22.0 또는 python 3.7.*과 numpy 1.* 모두 성공적인 환경을 이끌어낼 것입니다.

전이 종속성 충돌

비슷한 방식으로 패키지 충돌은 전이 종속성 때문에 발생할 수 있습니다. 전이 종속성의 특성으로 인해 몇 개의 패키지만 요청해도 수백 개의 제약 조건이 환경 해결 작업에 추가될 수 있습니다. statsmodels 패키지를 고려해 보세요:

statsmodels  # 통계 모델링을 위한 Python 라이브러리
├─ numpy  # 다차원 배열을 효율적으로 처리할 수 있는 Python 라이브러리
├─ scipy  # 과학 계산용 Python 라이브러리
├─ matplotlib  # 데이터 시각화를 위한 Python 라이브러리
│  │  ├─ libpng  # PNG 이미지를 처리하기 위한 라이브러리
│  │  ├─ setuptools  # Python 패키지 관리를 위한 라이브러리
│  │  ├─ cycler  # matplotlib의 스타일을 제어하기 위한 도구
│  │  ├─ dateutil  # 날짜와 시간을 처리하기 위한 라이브러리
│  │  └─ kiwisolver  # 복잡한 제약 조건을 해결하는데 사용되는 알고리즘 라이브러리

특정한 statsmodels 버전을 요청하면 matplotlib에 대한 패키지 종속성 때문에 허용되는 setuptools 버전에 제약이 발생할 수 있습니다. 따라서, 환경이 statsmodels와 setuptools의 호환되지 않는 버전을 요청하면 statsmodels 자체가 setuptools에 제한을 두는 방식으로 인해 전이 종속성 충돌이 발생할 수 있습니다.

예를 들어, 다음 환경은 huggingface-adapter 0.1.1*과 transforms 1.645.0을 요청합니다: 다음 패키지들은 호환되지 않습니다 ├─ huggingface-adapter 0.1.1** * 설치 가능하며, 이는 다음을 필요로 합니다. │ └─ palantir_models >=0.551.0 *, 이것은 다음을 필요로 합니다. │ └─ pyspark-src >=3.2.1,<3.3.0a0 *, 이것은 설치가 가능합니다. └─ transforms 1.645.0 * 설치할 수 없습니다. 왜냐하면 다음을 필요로 합니다. └─ pyspark-src 3.2.1_palantir.36 *, 이전에 보고된 설치 가능한 버전들과 충돌합니다. 처음에는 두 패키지가 호환되지 않는 이유가 분명하지 않을 수 있습니다. 오류 메시지는 huggingface-adapter의 전이 종속성이 transforms의 직접 종속성인 pyspark-src와 충돌하여 문제가 발생함을 확인하는데 도움이 됩니다. 이 환경은 transforms 또는 huggingface-adapter에 대한 제약 조건을 완화함으로써 Mamba가 호환되는 pyspark-src 요구 사항을 이끄는 버전 쌍을 식별할 수 있도록 해결할 수 있습니다.

새로운 오류 메시지 해석하기

아래에는 새로운 mamba 오류 메시지가 제공할 수 있는 가능한 모든 문구, 해석 방법, 그리고 이를 수정하는 방법에 대한 안내를 나열하였습니다:

• 다음 패키지들이 호환되지 않습니다 또는 다음 패키지를 설치할 수 없습니다: 이들 중 어느 것이든 일반적으로 자세한 오류 메시지의 첫 문장이 됩니다. 이것은 전체 문제가 호환되지 않는 버전으로 인한 패키지 충돌인지 아니면 필요한 패키지의 설치 자체에서 문제가 있는지를 나타냅니다.
  • 수정 방법: 직접 문장 아래에 있는 필요한 정보를 읽으십시오.
• 설치 가능합니다: 이 문장은 일반적으로 트리 종속성의 상단에 나타나며 패키지 자체는 추가 제약 조건 없이 설치할 수 있다는 것을 의미합니다. 그러나 이 특정 버전이 설치된 상태라고 가정하면, 다른 패키지 종속성과 충돌하는 문제가 발생할 수 있습니다. 예를 들어, python 3.7** 요청되었고 설치 가능합니다는 환경에 Python 3.7을 설치할 수 있다는 것을 의미합니다. 이 문장 아래에 직접 나열된 모든 충돌은 환경에 Python 3.7이 설치되어 있다고 가정합니다.
• 실행 가능한 옵션이 없습니다: 설치할 수 있는 버전 중 어느 것도 요청된 환경의 다른 사양으로 인해 부과된 제약 조건 내에서 맞출 수 없습니다. 예를 들어, python 3.7** 설치할 수 없습니다. 실행 가능한 옵션이 없기 때문입니다. 메시지는 python 3.7.* 버전들이 다른 패키지나 제약 조건이 특정한 다른 Python 버전을 요청하지 않는 한 설치될 수 있다는 것을 나타냅니다.
  • 수정 방법: 이 패키지의 실행 가능한 옵션 범위 외에 허용 가능한 버전 범위를 생성하는 패키지의 제약 조건을 완화하십시오.
• 존재하지 않거나(오타 또는 누락된 채널일 수 있습니다): 설치할 패키지를 찾을 수 없습니다. 이는 패키지가 잘못 지정되었거나 구성된 채널 중 어느 것도 패키지를 포함하지 않기 때문일 가능성이 큽니다(Code Repository에서 설정 > 라이브러리 또는 Code Workbook 환경 구성). 예를 들어, 환경에 python 3.423.*(존재하지 않는 버전) 및 pthon 3.8.*(분명한 오타)을 요청하면 다음과 같은 오류 메시지가 발생합니다:

 Could not solve for environment specs
  The following packages are incompatible
  ├─ pthon 3.8**  does not exist (perhaps a typo or a missing channel);  # pthon 3.8**이 존재하지 않습니다 (오타 또는 누락된 채널일 수 있습니다);
  └─ python 3.423** does not exist (perhaps a typo or a missing channel).  # python 3.423**이 존재하지 않습니다 (오타 또는 누락된 채널일 수 있습니다).

• 해결 방법: 패키지에 오타가 없는지 확인하거나, 모든 요청된 패키지가 환경에서 사용 가능한지 확인하십시오. Foundry에서 패키지의 존재를 어떻게 검색할 수 있는지에 대한 조언은 Python 라이브러리 찾기를 참조하십시오.

• 설치 가능하며 요구사항이 있다: 패키지와 그에 첨부된 버전은 환경에 설치될 수 있지만, 환경에 추가적인 제약조건을 도입할 것입니다.

• 설치할 수 없으며 요구사항이 있다: 패키지와 그에 첨부된 버전은 일부 종속성이 환경에서 충돌을 일으키기 때문에 설치할 수 없습니다.

  • 해결 방법: 메시지 아래에 나열된 종속성의 문제가 되는 요구사항을 조사하고 이들의 제약조건을 완화하거나, 이 특정 패키지의 제약조건을 완화하십시오.

• 선택적 옵션으로 설치 가능하다: 패키지에는 환경에 설치할 수 있는 충돌하지 않는 여러 버전이 있습니다. 이들 중 하나를 선택하면 추가적인 제약조건이 발생할 수 있습니다.

• 이전에 보고된 설치 가능한 버전과 충돌한다: 일반적으로 위의 줄에서 언급된 버전과 대조되어, 그 패키지의 설치 가능한 버전이 이미 결정되어 있고 이 버전은 따라서 만족시킬 수 없을 것이라는 것을 나타냅니다.

  • 해결 방법: 동일한 환경이 동일한 패키지의 두 가지 다른 버전을 요청하지 않도록 하십시오. 이는 직접적으로 또는 전이적으로 발생할 수 있습니다.

• 시스템에서 누락되었다: 이는 특히 누락된 가상 패키지를 특정합니다. 일부 패키지는 특정 OS 환경에서만 실행될 수 있습니다. 예를 들어, cudatoolkit 패키지는 __cuda의 특정 버전, 시스템 수준의 기능,이 환경에 가상 패키지로 존재하여 패키지가 기존 아키텍처에서 실행될 수 있도록 합니다.

• 설치할 수 없음 (이전에 설명한 바와 같이): 패키지는 이미 이전에 설명된 충돌 때문에 설치할 수 없거나, 다른 패키지가 이미 이전에 설명된 동일한 제약조건을 포함하고 있기 때문에 설치할 수 없습니다.

이전 Mamba 오류 메시지

아래에는 새로운 Mamba 오류 메시지가 도입되기 전의 이전 오류 메시지의 일반적인 오류 메시지 목록이 있습니다.

패키지를 찾을 수 없음

이 경우, 설정된 채널 중 어느 것도 패키지 A의 종속성을 제공하지 않습니다.

Copied!
1
문제: 요청된 A.a.a.a를 제공하는 것이 없습니다

이는 고정된 버젼의 패키지가 존재하지 않을 경우 발생할 수 있습니다. 이런 경우, meta.yml 내의 패키지에서 버젼을 완화하거나 제거해 보십시오; 예를 들면, matplotlib 1.1.1은 matplotlib이 될 수 있습니다.

이런 오류를 받게 되면, 아래의 애플리케이션 특정 지침을 따라 패키지를 추가할 수 있습니다:

• Code Repositories에서 패키지를 추가하는 방법에 대해 더 알아보기.
• Code Workbook에서 패키지를 추가하는 방법에 대해 더 알아보기.
• foundry_ml 모델에 패키지를 추가하는 방법에 대해 더 알아보기.

의존성을 찾을 수 없음

이 경우, 패키지 A는 필요한 의존성 B를 포함하고 있는데, 이는 어떠한 채널에도 제공되지 않았습니다.

Copied!
1
문제: A-a.a.a에 필요한 B-b.b.b를 제공하는 것이 없습니다:

B는 사용자가 명시적으로 요청한 패키지(meta.yml/foundry-ml/vector 프로필 내)이거나 이식 가능한 종속성일 수 있습니다.

B가 설치 가능한 목록에 없는 경우에 이런 상황이 발생할 수 있습니다; 예를 들어, B가 회수되어 설치 가능한 상태가 아닐 수 있습니다.

이런 경우가 발생하면, 모든 종속성이 사용 가능한 A의 버전이 있는지 확인하기 위해 고정된 A의 버전을 제거하거나, 필요한 패키지를 Foundry에 가져오기 위해 Palantir 담당자에게 연락해보세요.

중복 패키지 오류

Copied!
1
// X.a.b.c와 X.d.e.f를 동시에 설치할 수 없습니다.

이 오류는 같은 패키지 X를 설치하려고 하고 두 가지 버젼을 고정하려고 할 때 발생합니다. 예를 들어, meta.yml에서 python 3.9.*와 python 3.10.* 둘 다 고정하려고 시도하면 이 오류가 발생할 수 있습니다. 이 문제를 해결하려면 중복된 패키지 고정 중 하나를 제거하면 됩니다.

권한 오류 디버깅하기

Copied!
1
// CondaService: ReadRepositoryPermissionDenied (콘다서비스: 저장소 읽기 권한 거부)

이 오류를 받는 경우, 필요한 모든 에셋과 패키지가 등록에 사용할 수 없기 때문일 수 있습니다. 모든 항목이 등록에 설치되면 다시 배포하십시오.

패키지 충돌

이 경우, 패키지 A는 패키지 B의 버전에 대한 요구사항이 있지만, 이 B의 버전은 다른 패키지와 충돌합니다:

Copied!
1
문제: 패키지 A-a.a.a는 B >=2.2.5,<2.3.0a0를 필요로 하는데, 설치할 수 있는 제공자가 없습니다.

위의 코드는 JavaScript가 아닙니다. 이것은 패키지 설치 시 발생하는 문제를 설명하는 메시지입니다. 패키지 A-a.a.a가 B 버전 2.2.5 이상 및 2.3.0a0 미만을 필요로 하는데, 이 요구사항을 충족하는 패키지 제공자를 찾을 수 없다는 것을 의미합니다. 이 문제는 일반적으로 의존성 문제로 인해 발생하며, 적절한 버전의 패키지를 찾아 설치하거나, 필요한 경우 패키지의 버전을 변경하여 해결할 수 있습니다. B 패키지는 A의 전이적 종속성을 참조할 수 있음을 유의하십시오. 이는 meta.yaml 파일에서 명시적으로 요구 사항으로 명시하지 않았습니다. 전이적 종속성에 대한 자세한 내용은 환경 생성 소개를 참조하십시오.

패키지 충돌 디버깅하기

• 실패하는 해결의 최소한의 예제를 만듭니다. 환경이 성공적으로 해결될 때까지 패키지를 제거하고, 어떤 패키지가 방해가 되는지 결정할 때까지 패키지를 다시 추가합니다.

• 제약조건을 완화해보세요 (패키지 핀 제거).

  • 이 과정을 빠르게 하려면 여러 저장소 또는 동일 저장소의 여러 브랜치를 다른 창에서 열 수 있습니다 (Code Repositories에서) 또는 프로파일 (Code Workbook에서).

  Code Workbook에서는 pandas, matplotlib, 그리고 numpy에 대해 최소 버전을 추가하여 기본값이 pandas=0, matplotlib=2, numpy<1.20로 설정되는 것을 방지할 수 있습니다. 이 기본값보다 높은 버전이 필요한 경우 환경 > 스파크 환경 커스터마이즈 > 프로파일 커스터마이즈로 이동하고, 각 패키지에 대해 드롭다운 메뉴에서 버전을 선택하여 버전 요구사항을 충족시킵니다.

  

  • 이슈를 발견하는 데 이진 검색 사용을 추천합니다. 한 저장소에서 모든 제약 조건을 제거하고, 다른 저장소에서 제약 조건의 절반을 제거한 다음, 다른 저장소에서 나머지 절반을 제거하고, 그런 식으로 진행합니다.

• Mamba에서 생성되는 로그에 추가로 상세정보를 추가할 수도 있습니다. 이는 트리 하단의 전이적 종속성을 추적하는 데 도움이 될 수 있습니다 (주의: 이는 검사에서 속도 저하를 일으킵니다). 상세정보를 추가하려면, CI 로그에서 검사가 실패한 작업을 찾아 Execution failed for task ':transforms-python:<task-name>'. 라인을 찾습니다. 예를 들어 condaPackRun이 실패한 작업이었다면, 다음 블록을 내부 transforms-python/build.gradle 파일의 하단에 추가합니다:

Copied!
1
2
3
4
tasks.condaPackRun {
    // 추가 인수 "-vvv"를 사용합니다.
    additionalArguments "-vvv"
}

버젼 고정 해제가 resolve 실패를 고치지 못하는 이유는 무엇인가요?

완전히 완화된 제약조건에도 불구하고, 요구 사항 목록에 필요한 패키지 또는 패키지 버전이 다음과 같이 사용할 수 없거나 호환되지 않을 수 있습니다:

• 사용할 수 없음. 사용 가능한 패키지와 버전을 패키지 탭에서 확인할 수 있습니다. 필요한 경우, 팔란티어 대표에게 이 패키지들이 추가되도록 요청할 수 있습니다.
• 호환되지 않음. 이 패키지 정의들은 우리가 가능한 모든 게시된 버전에 접근할 수 있더라도 결코 호환되지 않을 수 있습니다. 예를 들어, 의존하고 있는 Conda 패키지 중 하나가 새 버전(업그레이드 PRs 참조)으로 업그레이드되어 깨질 수 있습니다.
• meta.yml에 있는 Python 버전과 호환되지 않음.

이 시나리오를 확인하기 위해 성공적인 체크와 실패한 체크의 Conda lock 파일을 비교할 수 있습니다. Conda lock 파일에 접근하려면 설정 톱니바퀴에서 숨긴 파일 및 폴더 보기 옵션을 선택하고, transforms-python/conda-versions.run.linux-64.lock로 이동합니다. 성공적인 실행과 실패한 실행 사이에 변경된 라이브러리의 버전을 meta.yaml 파일에서 다른 버전으로 고정합니다.

요청한 패키지에 변화가 없는 실패

이런 상황이 발생하는 두 가지 주요 이유는 다음과 같습니다:

1. 변환 작업이 외부 패키지에 의존할 수 있기 때문에(publicly managed Conda channels 참조), 유감스럽게도 상류에서 무언가가 깨질 경우에는 실패에 취약할 수 있습니다.
2. 업그레이드 PR을 병합하면 Checks가 실행될 때 환경의 재해석을 트리거하고, 드물게는 패키지 해석이 실패하게 만들 수 있습니다, 특히 과도하게 제한된 환경인 경우에는 그렇습니다. 이는 업그레이드 PRs가 새로운 종속성을 가져오기 때문에 환경이 재계산을 필요로 하게 됩니다. 업그레이드 PR이 원인이었는지 확인하기 위해 업그레이드 PR이 적용된 Commit을 되돌리면 Checks가 통과하는지 테스트할 수 있습니다. 그런 다음 위의 섹션을 통해 업그레이드 PR을 다시 적용할 수 있습니다.

meta.yml에 변화가 없는 경우의 느린 디버깅

Code Repositories에서:

1. 브랜치를 업그레이드하십시오(manual branch upgrade 참조를 참조하십시오).
2. 아직도 느림현상이 발생하고 @transform_df 태그 외부에서 코드 변경을 진행한 경우, 이 코드가 체크를 느리게 만들었을 수 있습니다. 이 코드의 성능을 평가하십시오(해당하는 경우).

meta.yml에 변화가 있었던 경우의 작업 시간 초과

오랫동안 실행되는 작업에서 메모리 부족(OOM) 에러를 받고 있다면, 이는 패키지의 호환되지 않는 버전으로 인해 해결할 수 없는 환경이 생겼을 수 있습니다. 이 문제를 해결하기 위해, 먼저 브랜치를 업그레이드한 다음, 위에 나열된 디버깅 단계를 수행하십시오.

Conda 오류와 함께 빌드 실패

Copied!
1
2
// Conda 환경 설정 오류
CondaEnvironmentSetupError

빌드 오류가 발생한 경우, 해결 단계는 다음과 같습니다:

1. 오류를 확인하기 위해 드라이버 로그를 확인하십시오.
2. 코드 또는 meta.yml에 변경 사항을 만든 경우 (작업 비교 도구를 이용하여 확인) 그러면 그것들을 되돌려 빌드가 수정되는지 확인하십시오. 되돌린 meta.yml 변경 사항이 문제를 해결하면 패키지 충돌이 있을 가능성이 있으며, 이는 위에 설명된 대로 디버깅할 수 있습니다. meta.yml을 변경하지 않았다면 빌드의 Python 모듈 버전을 확인하십시오(다음 단계에서 언급). 이것이 빌드를 해결하지 못하면, 분기 업그레이드 또는 기본 업그레이드(업그레이드 PR 보기)로 인해 해결할 수 없는 환경이 발생했을 수 있습니다. 이 경우 위에서 언급한 디버깅 단계를 확인해야 합니다.
3. 변경 사항이 없는 경우, 실패한 빌드에 비해 성공한 빌드를 실행한 Python 모듈 버전이 다른가요? "Infra details", "Environment" 그리고 *"SparkModuleVersion"*을 확인하십시오. 이 버전으로 되돌리는 것에 대해 Palantir 대표에게 문의하십시오.

다중 다운로드 실패

Copied!
1
2
// 런타임 에러: 다중 다운로드 실패
RuntimeError: Multi-download failed

이 오류는 패키지가 다운로드되는 아티팩트 채널에 접근 권한이 없거나, 아티팩트가 등록에 사용할 수 없음을 의미합니다. 실제 실패 사항은 드라이버 로그에서 확인할 수 있습니다.

이 저장소를 템플릿으로 사용하려는 경우, Conda 채널 목록으로 이동하여 나열된 채널에 경고가 있는지 확인해 보세요. 나열된 채널에 경고가 있는 경우, 다음 단계를 따르세요:

1. 깨진 채널 제거하기 (해당되는 경우 Palantir 대표에게 권한 요청)
2. 검사를 다시 실행하기.
3. 빌드를 다시 실행하기.

엔트리 포인트 오류로 인한 빌드 실패

Copied!
1
transforms._errors.EntryPointError: "키 {name}을(를) 찾을 수 없습니다. 저장소의 meta.yaml 및 setup.py 파일을 확인해 주세요."

이 오류는 빌드를 트리거하는 데 필요한 루트 파일에서 무언가 누락되었음을 의미합니다. 데이터셋 미리보기를 사용할 수 있지만, 빌드는 실패할 것입니다.

이 문제를 디버깅하기 위해 meta.yaml 또는 setup.py에서 필수 정보가 누락되었는지 확인해보세요. 참고로, 새로운 Python Code Repositories를 만들어 새로운 저장소의 meta.yaml과 setup.py 파일을 살펴볼 수 있습니다.

누락된 정보를 meta.yaml 및/또는 setup.py에 추가한 후, 변경사항을 커밋하고, 체크가 성공적으로 이루어진 후에 빌드를 다시 트리거하십시오.

Conda 패키지와 JAR를 모두 필요로 하는 패키지들

일부 패키지는 사용 가능하기 위해 Conda 패키지와 JAR를 모두 필요로 합니다. 일반적인 예로는 graphframes 패키지가 있습니다 (여기서 Conda 패키지는 Python API를 포함하고 JAR는 실제 구현을 포함합니다). Conda 패키지만 추가하고 필요한 JAR를 추가하지 않으면 다음과 같은 오류가 발생할 수 있습니다:

o257.loadClass.: java.lang.ClassNotFoundException:<클래스> // 클래스를 찾을 수 없는 예외

대안적으로, 다음과 같은 오류를 마주칠 수도 있습니다:

자바 클래스패스 참조 오류 - 사용 중인 파이썬 의존성이 클래스패스에 없는 자바 jar를 참조하려고 합니다. 최근에 추가한 파이썬 의존성을 확인하고, 필요한 자바 패키지(JARs)에 대한 의존성을 build.gradle 파일에 추가하세요.

이러한 패키지는 다음의 두 단계 과정을 통해 추가해야 합니다:

1. 패키지 탭을 통해 일반적인 방법으로 저장소에 Conda 패키지를 추가합니다.
2. 설정 콘에서 숨겨진 파일 및 폴더 표시 옵션을 선택하고, 내부의 transforms-python/build.gradle 파일을 선택합니다. 파일의 하단에 다음 블록을 추가합니다:

Copied!
1
2
3
4
dependencies { 
    // 의존성 설정
    condaJars '<group_name>:<name>:<version>' // 그룹명, 이름, 버전으로 구성된 Conda 패키지를 추가합니다.
}

이 패키지들이 단위 테스트에도 필요한 경우, 테스트 시간에 사용할 수 있도록 해야 합니다. 그렇게 하려면 다음의 블록을 gradle 파일에 추가하십시오 (테스팅 플러그인은 sparkJars 의존성보다 먼저 선언해야 한다는 것에 주의하십시오):

Copied!
1
2
3
4
5
6
7
8
9
// 테스팅 플러그인 적용
apply plugin: 'com.palantir.transforms.lang.pytest-defaults'

dependencies { 
    // conda 패키지 의존성 설정
    condaJars '<group_name>:<name>:<version>' 
    // 스파크 패키지 의존성 설정
    sparkJars '<group_name>:<name>:<version>' 
}

외부 라이브러리의 또 다른 예로 Conda 패키지와 JAR 모두를 필요로 하는 Spark-NLP 패키지가 있습니다. Spark-NLP의 JAR 종속성은 build.gradle 파일에 추가해야 한다는 점에 유의하세요.

먼저, 외부 라이브러리로 Spark-NLP 추가하기.

위에서 추가한 라이브러리 버전과 호환되는 JAR을 하위 프로젝트 내의 build.gradle 파일에 추가합니다. 일반적으로 transforms-python/build.gradle입니다. 예를 들어, 위의 Spark-NLP 라이브러리 버전이 5.0.2이므로 아래 단계에서는 버전 기대치를 충족하는 JAR을 추가할 것입니다. <group_name>:<name>:<version> 형식을 사용하여 다음 코드를 통해 build.gradle 스크립트에 JAR을 추가할 수 있습니다:

dependencies {
     // 'com.johnsnowlabs.nlp:spark-nlp_2.12:5.0.2'라는 종속성을 condaJars에 추가합니다.
     condaJars 'com.johnsnowlabs.nlp:spark-nlp_2.12:5.0.2'   
 }

이름에서 지정된 목표 버전이 불확실하다면, Maven (외부)을 방문하여 원하는 라이브러리를 검색하고 Foundry에서 관찰하는 라이브러리 버전에 대한 호환되는 목표 버전을 찾습니다.

의존성 충돌 피하기 위한 모범 사례

위에서 언급한 오류 중에서 가장 흔한 원인은 의존성 충돌입니다. 의존성 충돌을 줄이기 위해 다음의 모범 사례를 따르십시오.

의존성 충돌 피하기 위한 모범 사례: Python

Python에 대해 major.minor 버전 관리를 유지합니다.

• Code Repositories에서는 3.8.*, 3.9.*, 3.10.* 중에서 선택할 수 있습니다. 선택한 버전은 빌드와 실행 섹션 모두에 대해 고정되어야 합니다. Python 3.6.*, 3.7.*는 이제 사용되지 않으며, 계속 사용할 수는 있지만 2024년 1분기 이후에는 허용되지 않을 것입니다.

• Code Workbook에서는 자동을 필요한 버전 관리로 변경하여 버전 관리를 전환할 수 있습니다.

Python 버전 지원

Python 3.8부터 Foundry는 Python End Of Life에 정의된 시간표를 따르게 되므로, Python 버전이 생명 종료로 선언되면 플랫폼에서 지원되지 않습니다. 자세한 내용은 Python 버전 페이지를 확인해 보세요.

의존성 충돌 피하기 위한 모범 사례: Python 이외의 패키지

명시적으로 버전을 고정하는 것을 피하십시오. 이는 의존성 충돌을 초래할 수 있습니다. 심지어 major.minor 버전도 충돌을 일으킬 수 있습니다.

기타 문제

위의 지침이 문제를 해결하는 데 충분하지 않거나, 이 가이드의 범위를 벗어난 문제가 발생한 경우, Palantir 대표에게 연락하고 시도한 디버깅 단계의 세부 정보를 포함하세요.