blocks|key|3131799|text|SfDA中的钱伯斯说，当这个包使用“命名空间”机制时，应该使用“导入”，因为现在所有的包都需要使用它们，那么现在的答案可能是总是使用“导入”。在过去，包可以在没有实际名称空间的情况下加载，在这种情况下，您将需要使用Depends。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3131800|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Chambers in SfDA says to use 'Imports' when this package uses a 'namespace' mechanism and since all packages are now required to have them, then the answer might now be always use 'Imports'. In the past packages could have been loaded without actually having namespaces and in that case you would need to have used Depends.

blocks|key|245513|text|"Imports"比"Depends"更安全(与其他使用"Depends"的包相比，使用它的包也是更好的公民)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|245514|"Depends"指令试图通过将另一个包附加到主搜索路径(即search()返回的环境列表)来确保另一个包中的函数可用。但是，如果稍后加载的另一个包将同名函数放在较早的搜索路径上，则此策略可能会受挫。Chambers+(in+SoDA)使用函数"gam"的示例，可以在gam和mgcv包中找到该函数。如果加载了另外两个包，其中一个依赖于gam，另一个依赖于mgcv，则通过调用gam()找到的函数将取决于附加这两个包的顺序。不太好。|245515|任何支持包的函数都应该使用"Imports"指令(在<namespace:packageName>之后立即搜索)，而不是在常规搜索路径上。如果上面示例中的任何一个包使用了"Imports"机制(该机制还需要NAMESPACE文件中的import或importFrom指令)，问题将从两个方面得到改善。(1)包本身将获得对使用哪个mgcv函数的控制。(2)通过使主搜索路径远离导入的对象，甚至不会潜在地破坏其他包对其他mgcv函数的依赖。|245516|这就是为什么使用名称空间是一种很好的实践，为什么它现在由CRAN强制执行，以及(特别是)为什么使用"Imports"比使用"Depends"更安全。|245517|245518|编辑了以添加一个重要的警告：|BOLD|245519|不幸的是，上面的建议有一个one常见的例外:如果你的包依赖于一个包A，而这个包本身"Depends"在另一个包B上，那么你的包可能需要使用"Depends指令附加A。|245520|这是因为在编写package+A+B+中的函数时，期望将package+及其函数附加到path。|245521|"Depends"指令将加载并附加A包，此时A包自身的"Depends"指令将在连锁反应中导致B包也被加载和附加。A包中的函数将能够在B包中找到它们所依赖的函数。|245522|"Imports"指令将加载但不附加包A，并且既不加载也不附加包B。(毕竟，"Imports"期望包编写器使用名称空间机制，并且包A将使用"Imports"指向B中它需要访问的任何函数。)因此，您的函数对依赖于B包中的函数的A包中的任何函数的调用都将失败。|245523|唯一的两个解决方案是：|245524|使用+directive.|245525|Better让您的软件包附加package+A从长远来看，请联系package+A的维护者，并要求他们更仔细地构建其命名空间(用Martin+Morgan在this+related+answer).|ordered-list-item|245526|中的话说|245527|entityMap|0|LINK|mutability|MUTABLE|url|http://www.springer.com/statistics/computanional%2Bstatistics/book/978-0-387-75935-7|1|https://stackoverflow.com/questions/14808337/tmplot-is-in-namespace-but-its-dependencies-are-not-found/14813080#comment20749830_14813080^0|0|9|A|9|S|9|0|0|9|U|8|3E|5|3Q|3|3U|4|4O|3|4Y|4|58|5|32|7|0|0|D|9|Q|N|2D|9|2V|9|38|6|3F|A|4K|4|5S|4|0|1D|9|1P|9|0|0|3|B|0|D|3|X|1|15|9|1J|1|1X|8|29|1|0|F|1|H|1|J|G|10|7|F|1|H|1|0|0|9|H|1|M|1|R|9|1B|1|1L|1|1V|1|0|0|9|J|1|W|1|12|9|1T|1|1X|9|28|1|2X|1|34|1|0|0|0|M|1|14|1|26|J|1|0|0^^$0|@$1|2|3|4|5|6|7|1G|8|@$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]|$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1N|8|@$9|1O|A|1P|B|C]|$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]|$9|1W|A|1X|B|C]|$9|1Y|A|1Z|B|C]|$9|20|A|21|B|C]|$9|22|A|23|B|C]]|D|@$9|24|A|25|1|26]]|E|$]]|$1|H|3|I|5|6|7|27|8|@$9|28|A|29|B|C]|$9|2A|A|2B|B|C]|$9|2C|A|2D|B|C]|$9|2E|A|2F|B|C]|$9|2G|A|2H|B|C]|$9|2I|A|2J|B|C]|$9|2K|A|2L|B|C]|$9|2M|A|2N|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|2O|8|@$9|2P|A|2Q|B|C]|$9|2R|A|2S|B|C]]|D|@]|E|$]]|$1|L|3|-4|5|6|7|2T|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|2U|8|@$9|2V|A|2W|B|O]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|2X|8|@$9|2Y|A|2Z|B|O]|$9|30|A|31|B|C]|$9|32|A|33|B|C]|$9|34|A|35|B|C]|$9|36|A|37|B|C]|$9|38|A|39|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|3A|8|@$9|3B|A|3C|B|O]|$9|3D|A|3E|B|O]|$9|3F|A|3G|B|O]|$9|3H|A|3I|B|O]|$9|3J|A|3K|B|C]|$9|3L|A|3M|B|C]]|D|@]|E|$]]|$1|T|3|U|5|6|7|3N|8|@$9|3O|A|3P|B|C]|$9|3Q|A|3R|B|C]|$9|3S|A|3T|B|C]|$9|3U|A|3V|B|C]|$9|3W|A|3X|B|C]|$9|3Y|A|3Z|B|C]|$9|40|A|41|B|C]]|D|@]|E|$]]|$1|V|3|W|5|6|7|42|8|@$9|43|A|44|B|C]|$9|45|A|46|B|C]|$9|47|A|48|B|C]|$9|49|A|4A|B|C]|$9|4B|A|4C|B|C]|$9|4D|A|4E|B|C]|$9|4F|A|4G|B|C]|$9|4H|A|4I|B|C]|$9|4J|A|4K|B|C]]|D|@]|E|$]]|$1|X|3|Y|5|6|7|4L|8|@]|D|@]|E|$]]|$1|Z|3|10|5|6|7|4M|8|@]|D|@]|E|$]]|$1|11|3|12|5|13|7|4N|8|@$9|4O|A|4P|B|C]|$9|4Q|A|4R|B|C]]|D|@$9|4S|A|4T|1|4U]]|E|$]]|$1|14|3|15|5|6|7|4V|8|@]|D|@]|E|$]]|$1|16|3|-4|5|6|7|4W|8|@]|D|@]|E|$]]]|17|$18|$5|19|1A|1B|E|$1C|1D]]|1E|$5|19|1A|1B|E|$1C|1F]]]]

<code>"Imports"</code> is safer than <code>"Depends"</code> (and also makes a package using it a 'better citizen' with respect to other packages that do use <code>"Depends"</code>).

A <code>"Depends"</code> directive attempts to ensure that a function from another package is available by attaching the other package to the main search path (i.e. the list of environments returned by <code>search()</code>). This strategy can, however, be thwarted if another package, loaded later, places an identically named function earlier on the search path. Chambers (<a href="http://www.springer.com/statistics/computanional+statistics/book/978-0-387-75935-7" rel="noreferrer">in SoDA</a>) uses the example of the function <code>"gam"</code>, which is found in both the <code>gam</code> and <code>mgcv</code> packages. If two other packages were loaded, one of them depending on <code>gam</code> and one depending on <code>mgcv</code>, the function found by calls to <code>gam()</code> would depend on the order in which they those two packages were attached. Not good.

An <code>"Imports"</code> directive should be used for any supporting package whose functions are to be placed in <code>&lt;imports:packageName&gt;</code> (searched immediately after <code>&lt;namespace:packageName&gt;</code>), instead of on the regular search path. If either one of the packages in the example above used the <code>"Imports"</code> mechanism (which also requires <code>import</code> or <code>importFrom</code> directives in the <code>NAMESPACE</code> file), matters would be improved in two ways. (1) The package would itself gain control over which <code>mgcv</code> function is used. (2) By keeping the main search path clear of the imported objects, it would not even potentially break the other package's dependency on the other <code>mgcv</code> function.

This is why using namespaces is such a good practice, why it is now enforced by CRAN, and (in particular) why using <code>"Imports"</code> is safer than using <code>"Depends"</code>.

<hr>

Edited to add an important caveat:

There is one unfortunately common exception to the advice above: if your package relies on a package <code>A</code> which itself <code>"Depends"</code> on another package <code>B</code>, your package will likely need to attach <code>A</code> with a <code>"Depends</code> directive.

This is because the functions in package <code>A</code> were written with the expectation that package <code>B</code> and its functions would be attached to the <code>search()</code> path.

A <code>"Depends"</code> directive will load and attach package <code>A</code>, at which point package <code>A</code>'s own <code>"Depends"</code> directive will, in a chain reaction, cause package <code>B</code> to be loaded and attached as well. Functions in package <code>A</code> will then be able to find the functions in package <code>B</code> on which they rely.

An <code>"Imports"</code> directive will load but not attach package <code>A</code> and will neither load nor attach package <code>B</code>. (<code>"Imports"</code>, after all, expects that package writers are using the namespace mechanism, and that package <code>A</code> will be using <code>"Imports"</code> to point to any functions in <code>B</code> that it need access to.) Calls by your functions to any functions in package <code>A</code> which rely on functions in package <code>B</code> will consequently fail.

The only two solutions are to either:

<ol>
<li>Have your package attach package <code>A</code> using a <code>"Depends"</code> directive.</li>
<li>Better in the long run, contact the maintainer of package <code>A</code> and ask them to do a more careful job of constructing their namespace (in the words of Martin Morgan in <a href="https://stackoverflow.com/questions/14808337/tmplot-is-in-namespace-but-its-dependencies-are-not-found/14813080#comment20749830_14813080">this related answer</a>).</li>
</ol>

blocks|key|3131888|text|Hadley+Wickham给出了一个简单的解释(http://r-pkgs.had.co.nz/namespace.html)：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3131889|3131890|+在+Depends+或中列出软件包可确保在需要时进行安装。主要区别在于Imports仅加载软件包，而Depends会附加它。没有其他区别。..。|blockquote|style|BOLD|CODE|3131891|3131892|除非有其他好的理由，否则你应该总是在Imports+Depends**.+Depends**.中列出包，这是因为好的包是自包含的，并且最大限度地减少了对全局环境(包括搜索路径)的更改。唯一的例外是，如果您的软件包被设计为与另一个软件包一起使用。**例如，模拟软件包构建在素食的基础上。没有纯素食就没有用了，所以它在Depends而不是Imports中有纯素食。同样，ggplot2应该真正依赖于比例，而不是导入比例。|3131893|entityMap|0|LINK|mutability|MUTABLE|url|http://r-pkgs.had.co.nz/namespace.html^0|P|12|0|0|0|1|1|3|7|B|J|3|7|10|7|1F|7|0|0|I|7|Q|9|11|4R|I|7|Q|7|11|7|4D|7|4N|7|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|10|8|@$A|11|B|12|H|I]|$A|13|B|14|H|I]|$A|15|B|16|H|I]|$A|17|B|18|H|J]|$A|19|B|1A|H|J]|$A|1B|B|1C|H|J]]|9|@]|C|$]]|$1|K|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1E|8|@$A|1F|B|1G|H|I]|$A|1H|B|1I|H|I]|$A|1J|B|1K|H|I]|$A|1L|B|1M|H|J]|$A|1N|B|1O|H|J]|$A|1P|B|1Q|H|J]|$A|1R|B|1S|H|J]|$A|1T|B|1U|H|J]]|9|@]|C|$]]|$1|N|3|-4|5|6|7|1V|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

Hadley Wickham gives an easy explanation (<a href="http://r-pkgs.had.co.nz/namespace.html">http://r-pkgs.had.co.nz/namespace.html</a>):

<blockquote>
 Listing a package in either <code>Depends</code> or <code>Imports</code> ensures that it’s
 installed when needed. The main difference is that where <code>Imports</code> just
 loads the package, <code>Depends</code> attaches it. There are no other
 differences. [...]
 
 Unless there is a good reason otherwise, you should always list
 packages in <code>Imports</code> not <code>Depends</code>. That’s because a good package is
 self-contained, and minimises changes to the global environment
 (including the search path). The only exception is if your package is
 designed to be used in conjunction with another package. For example,
 the analogue package builds on top of vegan. It’s not useful without
 vegan, so it has vegan in <code>Depends</code> instead of <code>Imports</code>. Similarly,
 ggplot2 should really Depend on scales, rather than Importing it.
</blockquote>

blocks|key|3131975|text|下面是一个简单的问题，可以帮助您决定使用哪一个：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3131976|您的软件包是否要求+end+user+能够直接访问其他软件包的功能？|offset|length|style|BOLD|3131977|3131978|NO+->+Imports+(最常见的答案)|unordered-list-item|3131979|YES+->依赖|3131980|3131981|当你的包是另一个包的附加组件或伴生包时，你唯一应该使用'Depends‘的时候，你的最终用户将在他们的代码中使用来自你的包和'Depends’包的函数。如果您的最终用户将只与您的函数交互，而另一个包将仅在幕后执行工作，那么请使用“Imports”。|3131982|需要注意的是，如果你像往常一样向'Imports‘中添加了一个包，你的代码将需要引用该包中的函数，使用完整的命名空间语法，例如dplyr::mutate()，而不仅仅是mutate()。这使得代码读起来有点笨拙，但对于更好的包卫生来说，这是一个很小的代价。|CODE|3131983|entityMap^0|0|0|9|A|8|J|F|0|0|0|0|0|0|1R|F|2C|8|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]|$D|Z|E|10|F|G]|$D|11|E|12|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|15|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|18|8|@$D|19|E|1A|F|S]|$D|1B|E|1C|F|S]]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|U|$]]

Here is a simple question to help you decide which to use:

Does your package require the end user to have direct access to the functions of another package?

<ul>
<li>NO -> Imports (most common answer)</li>
<li>YES -> Depends</li>
</ul>

The only time you should use 'Depends' is when your package is an add-on or companion to another package, where your end user will be using functions from both your package and the 'Depends' package in their code. If your end user will only be interfacing with your functions, and the other package will only be doing work behind the scenes, then use 'Imports' instead.

The caveat to this is that if you add a package to 'Imports', as you usually should, your code will need to refer to functions from that package, using the full namespace syntax, e.g. <code>dplyr::mutate()</code>, instead of just <code>mutate()</code>. It makes the code a little clunkier to read, but it’s a small price to pay for better package hygiene.

The "<a href="http://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file" rel="noreferrer">Writing R Extensions</a>" manual provides the following guidance on when to use Imports or Depends:

<blockquote>
 The general rules are
 
 <ul>
 <li>Packages whose namespace only is needed to load the package using library(pkgname) must be listed in the ‘Imports’ field and not in the
 ‘Depends’ field.</li>
 <li>Packages that need to be attached to successfully load the package using library(pkgname) must be listed in the ‘Depends’ field, only.</li>
 </ul>
</blockquote>

Can someone provide a bit more clarity on this? How do I know when my package only needs namespaces loaded versus when I need a package to be attached? What are examples of both? I think the typical package is just a collection of functions that sometimes call functions in other packages (where some bit of work has already been coded-up). Is this scenario 1 or 2 above?

Edit

I wrote a <a href="http://blog.obeautifulcode.com/R/How-R-Searches-And-Finds-Stuff/" rel="noreferrer">blog post</a> with a section on this specific topic (search for 'Imports v Depends'). The visuals make it a lot easier to understand.

Better explanation of when to use Imports/Depends

"“手册提供了以下关于何时使用导入或依赖的指导：一般规则是使用库(Pkgname)加载包时只需要其命名空间的包必须列在“Imports”字段中，而不是列在“Depends”field.Packages中。要使用库(Pkgname)成功加载包，需要附加这些包的包必须只列在“Depends”字段中。有人能说得更清楚一点吗？...

问更好地解释何时使用导入/依赖
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问更好地解释何时使用导入/依赖EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问更好地解释何时使用导入/依赖
EN