[r] 가져 오기 / 의존적 사용시기에 대한 더 나은 설명
” R 확장 프로그램 작성 “매뉴얼은 가져 오기 또는 종속성 사용시기에 대한 다음 지침을 제공합니다.
일반적인 규칙은
- library (pkgname)를 사용하여 패키지를로드하는 데 네임 스페이스 만 필요한 패키지는 ‘Depends’필드가 아닌 ‘Imports’필드에 나열되어야합니다.
- library (pkgname)를 사용하여 패키지를 성공적으로로드하기 위해 첨부해야하는 패키지는 ‘종속’필드에만 나열되어야합니다.
누군가 이것에 대해 좀 더 명확하게 할 수 있습니까? 패키지에 네임 스페이스 만로드해야하는시기와 패키지를 연결해야하는시기를 어떻게 알 수 있습니까? 둘의 예는 무엇입니까? 일반적인 패키지는 다른 패키지 (일부 작업이 이미 코딩 된 경우)에서 함수를 호출하는 함수 모음 일뿐입니다. 이 시나리오가 위의 1 또는 2입니까?
편집하다
이 특정 주제에 대한 섹션이 있는 블로그 게시물 을 작성했습니다 ( ‘Imports v Depends’검색). 시각 자료는 이해하기 훨씬 쉽습니다.
답변
"Imports"보다 안전합니다 "Depends"(또한 사용하는 다른 패키지와 관련하여 ‘더 나은 시민’을 사용하여 패키지를 만듭니다 "Depends").
"Depends"지시 시도는 다른 패키지에서 함수는 주 검색 경로 (에 의해 반환되는 환경, 즉 목록을 다른 패키지를 부착하여 사용할 수 있는지 확인합니다 search()). 그러나 나중에로드 된 다른 패키지가 검색 경로에서 동일한 이름의 함수를 이전에 배치하면이 전략을 방해 할 수 있습니다. 챔버 ( SoDA에서 )는 함수의 예를 사용하는데 "gam",이 함수 는 패키지 gam와 mgcv패키지 모두에 있습니다. 두 개의 다른 패키지가로드 된 경우 (그중 하나는에 의존하고 다른 패키지는 gam하나에 따라 달라짐) mgcv호출에 의해 발견되는 기능 gam()은 두 패키지가 연결된 순서에 따라 달라집니다. 안좋다.
"Imports"지시자는 그 기능에 배치되어 어떠한지지 패키지 표기 <imports:packageName>(직후 검색 <namespace:packageName>대신 일반 검색 경로로). 예제의 패키지 중 하나가 위의 사용한 경우 "Imports"(도 필요 메커니즘 import또는 importFrom의 지시 NAMESPACE파일), 문제는 두 가지 방법으로 개선 될 것이다. (1) 패키지 자체 mgcv는 어떤 기능이 사용 되는지에 대한 제어권을 얻습니다 . (2) 메인 검색 경로에서 가져온 객체를 제거하면 다른 패키지의 다른 mgcv기능 에 대한 종속성이 손상되지 않을 수도 있습니다.
그렇기 때문에 네임 스페이스를 사용하는 것이 좋은 습관이고, 이제는 CRAN에 의해 시행되는 이유, 특히 사용하는 "Imports"것이보다 안전한 이유 "Depends"입니다.
중요한 경고를 추가하기 위해 편집 :
이 하나 개 위의 조언 불행하게도 일반적인 예외 : 패키지는 패키지에 의존하는 경우 A자체 "Depends"다른 패키지에서 B, 패키지가 가능성 첨부해야합니다 A와 "Depends지시어.
때문입니다 패키지의 기능 A패키지 것이라는 기대로 기록 된 B그 기능이 부착 될 search()경로 .
"Depends"지시어는로드 패키지를 첨부 할 A어떤 순간 패키지에서 A의 자신의 "Depends"지시는, 연쇄 반응에 원인 패키지가됩니다 B로드와 연결도 할 수 있습니다. A그러면 패키지 의 함수는 패키지 B에서 함수가 의존 하는 함수를 찾을 수 있습니다 .
"Imports"지시어는로드 것이지만 되지 패키지를 첨부 A과 의지 도 부하 도 패키지를 연결합니다 B. ( "Imports"모든 후, 해당 패키지 작가 네임 스페이스 메커니즘을 사용하고 해당 패키지가 기대하는 A사용됩니다 "Imports"의 모든 기능에 포인트 B.이 액세스를 필요로하는) 패키지의 모든 기능에 대한 당신의 함수에 의해 호출 A패키지의 기능에 의존하는 B의지 결과적으로 실패합니다.
유일한 두 가지 솔루션은 다음 중 하나입니다.
- 지시문을
A사용 하여 패키지에 패키지 를 첨부하십시오"Depends". - 장기적으로는 패키지 관리자
A에게 문의하여 네임 스페이스를보다 신중하게 작성하도록 요청하십시오 ( 이 관련 답변 에서 Martin Morgan의 말로 ).
답변
Hadley Wickham은 쉬운 설명을 제공합니다 ( http://r-pkgs.had.co.nz/namespace.html ).
패키지를 나열
Depends하거나Imports필요할 때 설치되도록합니다. 가장 큰 차이점은Imports패키지를로드하고Depends연결하는 위치입니다. 다른 차이점은 없습니다. […]특별한 이유가없는 한, 패키지를 항상
Importsnot에 나열해야합니다Depends. 좋은 패키지는 자체적으로 포함되어 있고 검색 경로를 포함한 글로벌 환경의 변경을 최소화하기 때문입니다. 패키지가 다른 패키지와 함께 사용되도록 설계된 경우는 예외입니다. 예를 들어 아날로그 패키지는 완전 채식 위에 구축됩니다. 완전 채식 없이는 유용하지 않으므로Depends대신 완전 채식을 사용하십시오Imports. 마찬가지로 ggplot2는 가져 오기보다는 스케일에 의존해야합니다.
답변
SfDA의 Chambers는이 패키지가 ‘네임 스페이스’메커니즘을 사용할 때 ‘Imports’를 사용하고 모든 패키지에이를 가져야하므로 항상 ‘Imports’를 사용할 수 있다고합니다. 과거에는 실제로 네임 스페이스가 없어도 패키지를로드 할 수 있었으며이 경우 Depends를 사용해야했습니다.
답변
사용할 것을 결정하는 데 도움이되는 간단한 질문이 있습니다.
패키지가 최종 사용자 에게 다른 패키지의 기능에 직접 액세스 할 수 있어야합니까?
- NO-> 수입 (가장 일반적인 답변)
- 예-> 따라 달라집니다
‘Depends’를 사용해야하는 유일한 시점은 패키지가 다른 패키지의 애드온 또는 동반자 일 때이며, 최종 사용자는 패키지와 ‘Depends’패키지의 기능을 코드로 사용하게됩니다. 최종 사용자가 함수와 만 인터페이스하고 다른 패키지가 배후에서 작업을 수행하는 경우 ‘가져 오기’를 대신 사용하십시오.
주의 할 점은, 일반적으로 ‘Imports’에 패키지를 추가하면 코드가 전체 네임 스페이스 구문 (예 : dplyr::mutate()그냥 대신)을 사용하여 해당 패키지의 함수를 참조해야한다는 것입니다 mutate(). 코드를 읽기가 조금 어려워 지지만 더 나은 패키지 위생을 위해 지불하는 비용은 적습니다.
