r yaxt 수입/의존성 사용시기에 대한 더 나은 설명




xlab size in r (4)

" R 확장 작성 "설명서는 가져 오기 또는 의존을 사용할시기에 대한 다음 지침을 제공합니다.

일반적인 규칙은 다음과 같습니다.

  • 라이브러리 (pkgname)를 사용하여 패키지를로드하는 데 네임 스페이스 만 필요한 패키지는 '종속'필드가 아니라 '가져 오기'필드에 나열되어야합니다.
  • 라이브러리 (pkgname)를 사용하여 패키지를 성공적으로로드하기 위해 첨부해야하는 패키지는 '종속'필드에만 나열되어야합니다.

누군가가 이것에 대해 좀 더 명확하게 설명 할 수 있습니까? 내 패키지에 네임 스페이스 만로드해야하는지 아니면 패키지를 첨부해야 하는지를 어떻게 알 수 있습니까? 두 가지의 예는 무엇입니까? 제 생각에 전형적인 패키지는 다른 패키지의 함수를 호출하는 기능 모음 일뿐입니다 (일부 작업은 이미 코딩되어 있습니다). 위 시나리오 1 또는 2가 있습니까?

편집하다

이 특정 주제에 대한 섹션이있는 블로그 게시물 을 작성했습니다 ( 'Imports v Depends'검색). 영상으로 이해하기가 훨씬 쉬워집니다.


SfDA의 Chambers는이 패키지가 '네임 스페이스 (namespace)'메커니즘을 사용하고 모든 패키지에 지금 필요한 패키지가 있기 때문에 '가져 오기'를 사용한다고 말하면 이제 대답은 항상 '가져 오기'를 사용하게됩니다. 과거에는 실제로 네임 스페이스가 없어도 패키지가로드되었을 수 있었고이 경우 Depends를 사용해야했습니다.


"Imports""Depends" 보다 안전합니다 (또한 "Depends" 사용하는 다른 패키지와 관련하여 '더 나은 시민'을 사용하여 패키지를 만듭니다).

"Depends" 지시어는 다른 패키지를 기본 검색 경로 (즉, search() 의해 반환 된 환경 목록)에 첨부하여 다른 패키지의 함수를 사용할 수 있는지 확인하려고 시도합니다. 그러나 나중에로드 된 다른 패키지가 동일한 경로로 검색 경로에 먼저 배치되면이 전략을 방해 할 수 있습니다. Chambers ( SoDA )는 gammgcv 패키지에서 모두 발견되는 "gam" 함수의 예제를 사용합니다. 두 개의 다른 패키지가로드 된 경우 하나는 gam 에 따라, 하나는 mgcv 에 따라 gam() 에 대한 호출에 의해 발견되는 함수는 두 패키지가 첨부 된 순서에 따라 달라집니다. 안좋다.

"Imports" 지시어는 가져온 패키지를 일반 검색 경로가 아닌 <imports:packageName> ( <namespace:packageName> 바로 다음에서 검색)에 배치합니다. 위 예제의 패키지 중 하나에서 "Imports" 메커니즘을 사용하면 두 가지 측면에서 문제가 개선됩니다. (1) 패키지 자체가 mgcv 함수가 사용되는 것을 제어합니다. (2) 가져온 객체에서 메인 검색 경로를 깨끗하게 유지하면 다른 패키지에 대한 다른 mgcv 함수 의존성이 손상 될 가능성조차 없습니다.

이런 이유로 네임 스페이스를 사용하는 것이 좋은 연습이며 왜 지금 CRAN에 의해 ​​시행되고 왜 "Imports" 사용하는 것이 "Depends" 사용하는 것보다 안전한지에 대한 이유입니다.

중요한주의 사항을 추가하기 위해 편집 됨 :

불행히도 위의 조언에 대한 하나의 예외가 있습니다 : 패키지가 다른 패키지 B"Depends" 하는 패키지 A 를 사용하는 경우 패키지는 "Depends 지시문 "Depends 과 함께 A 를 첨부해야합니다.

이것은 패키지 A 의 함수가 패키지 B 와 그 함수가 search() 경로에 첨부 될 것이라는 기대로 작성 되었기 때문입니다.

"Depends" 지시문은 패키지 A 로드하고 연결합니다 A 이 시점에서 패키지 A 의 자체 "Depends" 지시문은 연쇄 반응에서 패키지 B 가로드되고 연결되도록합니다. 그러면 패키지 A 의 함수는 의존하는 패키지 B 의 함수를 찾을 수 있습니다.

"Imports" 지시어는 패키지 A 로드하지만로드 하지 않으며 패키지 B 로드 하거나 첨부 하지 않습니다 . 결국 "Imports" 는 패키지 작성자가 네임 스페이스 메커니즘을 사용하고 있으며 패키지 A 가 액세스 할 필요가있는 B 모든 기능을 가리키는 "Imports" 를 사용하게 될 것이라고 기대합니다. 패키지 B 기능에 의존하는 패키지 B 는 결과적으로 실패합니다.

유일한 두 가지 해결책은 다음 중 하나입니다.

  1. 패키지에 "Depends" 지시문을 사용하여 패키지 A 를 첨부하십시오.
  2. 장기적으로는 패키지 A 의 관리자에게 연락하여 네임 스페이스를 구성하는 데 더 신중한 작업을하도록 요청하십시오 ( 이 관련 답변 에서 Martin Morgan의 말로).

어떤 것을 사용할 지 결정하는 데 도움이되는 간단한 질문이 있습니다.

패키지가 일반 사용자 가 다른 패키지의 기능에 직접 액세스해야합니까?

  • 아니오 -> 수입 (가장 일반적인 대답)
  • 예 -> 의존

'의존'을 사용해야하는 유일한 방법은 패키지가 다른 패키지의 애드온 또는 컴패니언 일 때입니다. 여기서 최종 사용자는 패키지에서 패키지의 'Depends'패키지의 기능을 사용하게됩니다. 최종 사용자가 자신의 기능과 만 인터페이싱을하고, 다른 패키지가 뒤에서 작업을 수행하는 경우 대신 '가져 오기'를 사용하십시오.

이것에 대한주의 사항은 'Imports'에 패키지를 추가하면 대개 dplyr::mutate() 코드가 전체 네임 스페이스 구문을 사용하여 패키지의 함수를 참조해야합니다 (예 : dplyr::mutate() . mutate() . 이 코드는 코드를 읽기가 약간 까다롭지 만 패키지 위생을 개선하는 데는 적은 비용이 듭니다.


Hadley Wickham이 쉽게 설명해줍니다 ( http://r-pkgs.had.co.nz/namespace.html ).

Depends 또는 Imports 패키지를 나열하면 필요할 때 패키지가 설치됩니다. 가장 큰 차이점은 Imports 가 패키지를로드하는 경우 Depends 가 패키지를 첨부한다는 것입니다. 다른 차이점은 없습니다. [...]

그렇지 않은 정당한 이유가없는 한 항상 Imports Depends 패키지를 나열해야합니다. 이는 훌륭한 패키지가 자체 포함되어 있으며 글로벌 환경 (검색 경로 포함)의 변경을 최소화하기 때문입니다. 유일한 예외는 귀하의 패키지가 다른 패키지와 함께 사용되도록 설계된 경우입니다. 예를 들어, 아날로그 패키지는 완전 채식 위에 만들어집니다. 비건 채식을하지 않으면 유용하지 않으므로 Imports 대신에 Depends 가 채식을합니다. 마찬가지로 ggplot2는 실제로 가져 오기가 아닌 비율에 따라 달라야합니다.





r