R: use magrittr pipe operator in self written package
I would like to use the pipe-operator %>% introduced in the magrittr package in a package I wrote myself to chain dplyr data transformations. magrittr is listed as Import in the DESCRIPTION file. After loading my own package and testing the function which uses the pipe-operator I get the following error message:
Error in functionname(parameter, : could not find function "%>%"
Changing %>% to magrittr::%>% in the function source code does not help either because the package cannot be built anymore.
r namespaces magrittr
add a comment |
I would like to use the pipe-operator %>% introduced in the magrittr package in a package I wrote myself to chain dplyr data transformations. magrittr is listed as Import in the DESCRIPTION file. After loading my own package and testing the function which uses the pipe-operator I get the following error message:
Error in functionname(parameter, : could not find function "%>%"
Changing %>% to magrittr::%>% in the function source code does not help either because the package cannot be built anymore.
r namespaces magrittr
2
I would advise against the pipe operator inside a function inside a package. It makes debugging a lot harder (the call stack gets insanely deep with the pipe). For packages I'd just overwrite a temporary variable, which makes testing a lot easier (think: R telling you on what line the error occurred). The pipe is fine for interactive use but for programming it can be a burden.
– Mark van der Loo
May 23 '17 at 12:55
add a comment |
I would like to use the pipe-operator %>% introduced in the magrittr package in a package I wrote myself to chain dplyr data transformations. magrittr is listed as Import in the DESCRIPTION file. After loading my own package and testing the function which uses the pipe-operator I get the following error message:
Error in functionname(parameter, : could not find function "%>%"
Changing %>% to magrittr::%>% in the function source code does not help either because the package cannot be built anymore.
r namespaces magrittr
I would like to use the pipe-operator %>% introduced in the magrittr package in a package I wrote myself to chain dplyr data transformations. magrittr is listed as Import in the DESCRIPTION file. After loading my own package and testing the function which uses the pipe-operator I get the following error message:
Error in functionname(parameter, : could not find function "%>%"
Changing %>% to magrittr::%>% in the function source code does not help either because the package cannot be built anymore.
r namespaces magrittr
r namespaces magrittr
edited Jan 16 '15 at 8:13
tonytonov
18.1k156281
18.1k156281
asked Jan 14 '15 at 16:06
alexander kethalexander keth
40547
40547
2
I would advise against the pipe operator inside a function inside a package. It makes debugging a lot harder (the call stack gets insanely deep with the pipe). For packages I'd just overwrite a temporary variable, which makes testing a lot easier (think: R telling you on what line the error occurred). The pipe is fine for interactive use but for programming it can be a burden.
– Mark van der Loo
May 23 '17 at 12:55
add a comment |
2
I would advise against the pipe operator inside a function inside a package. It makes debugging a lot harder (the call stack gets insanely deep with the pipe). For packages I'd just overwrite a temporary variable, which makes testing a lot easier (think: R telling you on what line the error occurred). The pipe is fine for interactive use but for programming it can be a burden.
– Mark van der Loo
May 23 '17 at 12:55
2
2
I would advise against the pipe operator inside a function inside a package. It makes debugging a lot harder (the call stack gets insanely deep with the pipe). For packages I'd just overwrite a temporary variable, which makes testing a lot easier (think: R telling you on what line the error occurred). The pipe is fine for interactive use but for programming it can be a burden.
– Mark van der Loo
May 23 '17 at 12:55
I would advise against the pipe operator inside a function inside a package. It makes debugging a lot harder (the call stack gets insanely deep with the pipe). For packages I'd just overwrite a temporary variable, which makes testing a lot easier (think: R telling you on what line the error occurred). The pipe is fine for interactive use but for programming it can be a burden.
– Mark van der Loo
May 23 '17 at 12:55
add a comment |
4 Answers
4
active
oldest
votes
It should have worked correctly if you had magrittr listed in Depends. However, this is not advised. Instead, you leave magrittr in Imports and add the following line to NAMESPACE:
importFrom(magrittr,"%>%")
I suggest reading Writing R extensions. Your question is covered in paragraphs 1.1.3 and 1.5.1.
1
Thanks, that solved the problem.
– alexander keth
Jan 19 '15 at 11:37
1
@alexanderketh In that case you should hit the green tick mark next to the answer to mark it as accepted. Welcome to SO!
– tonytonov
Jan 19 '15 at 12:03
43
If you're usingroxygen2, you could add#' importFrom magrittr "%>%"to have NAMESPACE populated automatically duringroxygenize().
– Roman Luštrik
Feb 11 '15 at 15:20
27
@RomanLuštrik, just missing @, should be#' @importFrom magrittr "%>%"
– Roah
Aug 14 '15 at 18:05
7
Note that this will only allow you to use%>%internally in your package. If your API requires users to chain functions using%>%, they will still have to explicitly loadmagrittr. One way to solve this problem is to re-export the function. Here is an example of how to do it.
– Ramnath
Dec 28 '15 at 7:10
|
show 1 more comment
One additional solution - use the roxygen package. It's implemented as part of the devtools package. Once devtools is installed, calling devtools::document() will update your NAMESPACE for you. It also auto-builds .Rd files with documentation, which is handy.
All you do is add a special comment in the format #' @import packagename to a file to import all functions from that package, or #' @importFrom packagename functionname to import a function. You can have as many of these comments as you want in your files, so you can have a set of them at the top of each file, or with each of your functions that needs an external function.
Then you run devtools::document() and it parses your code looking for those comments, and then it creates an appropriate NAMESPACE file for you. Easy.
When I do this, it messes up the following oxygen comments that pertain to the help file for the first function in the R script. How do I separate global oxygen comments from the help file ones?
– jzadra
Oct 24 '17 at 21:36
2
I usually put the import comments with each function individually. That way if other functions in the file change, your imports stay accurate. So then there are no global definitions.
– Mike Stanley
Oct 24 '17 at 21:39
add a comment |
Assuming that you're using RStudio, Hadley's devtools package, and listed magrittr in the Imports section of the DESCRIPTION file, here are steps I took to make %>% work in my package function(s).
First, write function foo.R:
#' Convert code{data.frame} to code{list}.
#'
#' @importFrom magrittr %>%
#' @name %>%
#' @rdname pipe
#' @export
#' @param x A code{data.frame} object.
#' @examples
#' my_result <- foo(iris)
#'
foo <- function(x) {
x %>%
as.list()
}
Second, run devtools::document().
Third, run devtools::load_all().
A file like this will be created in your R/ directory and your function should work as expected.
3
what is the purpose of@name %>%here?
– Jelena-bioinf
Mar 27 '18 at 14:52
add a comment |
There's now an easier way to support the pipe in your packages. The wonderful package usethis has the function use_pipe(). You run that function once and it handles everything. This is how the use_pipe() function is described in the usethis documentation:
Does setup necessary to use magrittr's pipe internally in your package
and to re-export it for users of your package:
Adds magrittr to "Imports" in DESCRIPTION
Creates R/utils-pipe.R with the necessary roxygen template
1
I love this way, thanks.
– Shixiang Wang
Jan 7 at 4:28
You're very welcome!
– Andrew Brēza
Feb 4 at 20:05
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f27947344%2fr-use-magrittr-pipe-operator-in-self-written-package%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
It should have worked correctly if you had magrittr listed in Depends. However, this is not advised. Instead, you leave magrittr in Imports and add the following line to NAMESPACE:
importFrom(magrittr,"%>%")
I suggest reading Writing R extensions. Your question is covered in paragraphs 1.1.3 and 1.5.1.
1
Thanks, that solved the problem.
– alexander keth
Jan 19 '15 at 11:37
1
@alexanderketh In that case you should hit the green tick mark next to the answer to mark it as accepted. Welcome to SO!
– tonytonov
Jan 19 '15 at 12:03
43
If you're usingroxygen2, you could add#' importFrom magrittr "%>%"to have NAMESPACE populated automatically duringroxygenize().
– Roman Luštrik
Feb 11 '15 at 15:20
27
@RomanLuštrik, just missing @, should be#' @importFrom magrittr "%>%"
– Roah
Aug 14 '15 at 18:05
7
Note that this will only allow you to use%>%internally in your package. If your API requires users to chain functions using%>%, they will still have to explicitly loadmagrittr. One way to solve this problem is to re-export the function. Here is an example of how to do it.
– Ramnath
Dec 28 '15 at 7:10
|
show 1 more comment
It should have worked correctly if you had magrittr listed in Depends. However, this is not advised. Instead, you leave magrittr in Imports and add the following line to NAMESPACE:
importFrom(magrittr,"%>%")
I suggest reading Writing R extensions. Your question is covered in paragraphs 1.1.3 and 1.5.1.
1
Thanks, that solved the problem.
– alexander keth
Jan 19 '15 at 11:37
1
@alexanderketh In that case you should hit the green tick mark next to the answer to mark it as accepted. Welcome to SO!
– tonytonov
Jan 19 '15 at 12:03
43
If you're usingroxygen2, you could add#' importFrom magrittr "%>%"to have NAMESPACE populated automatically duringroxygenize().
– Roman Luštrik
Feb 11 '15 at 15:20
27
@RomanLuštrik, just missing @, should be#' @importFrom magrittr "%>%"
– Roah
Aug 14 '15 at 18:05
7
Note that this will only allow you to use%>%internally in your package. If your API requires users to chain functions using%>%, they will still have to explicitly loadmagrittr. One way to solve this problem is to re-export the function. Here is an example of how to do it.
– Ramnath
Dec 28 '15 at 7:10
|
show 1 more comment
It should have worked correctly if you had magrittr listed in Depends. However, this is not advised. Instead, you leave magrittr in Imports and add the following line to NAMESPACE:
importFrom(magrittr,"%>%")
I suggest reading Writing R extensions. Your question is covered in paragraphs 1.1.3 and 1.5.1.
It should have worked correctly if you had magrittr listed in Depends. However, this is not advised. Instead, you leave magrittr in Imports and add the following line to NAMESPACE:
importFrom(magrittr,"%>%")
I suggest reading Writing R extensions. Your question is covered in paragraphs 1.1.3 and 1.5.1.
edited May 23 '17 at 11:46
Community♦
11
11
answered Jan 16 '15 at 8:11
tonytonovtonytonov
18.1k156281
18.1k156281
1
Thanks, that solved the problem.
– alexander keth
Jan 19 '15 at 11:37
1
@alexanderketh In that case you should hit the green tick mark next to the answer to mark it as accepted. Welcome to SO!
– tonytonov
Jan 19 '15 at 12:03
43
If you're usingroxygen2, you could add#' importFrom magrittr "%>%"to have NAMESPACE populated automatically duringroxygenize().
– Roman Luštrik
Feb 11 '15 at 15:20
27
@RomanLuštrik, just missing @, should be#' @importFrom magrittr "%>%"
– Roah
Aug 14 '15 at 18:05
7
Note that this will only allow you to use%>%internally in your package. If your API requires users to chain functions using%>%, they will still have to explicitly loadmagrittr. One way to solve this problem is to re-export the function. Here is an example of how to do it.
– Ramnath
Dec 28 '15 at 7:10
|
show 1 more comment
1
Thanks, that solved the problem.
– alexander keth
Jan 19 '15 at 11:37
1
@alexanderketh In that case you should hit the green tick mark next to the answer to mark it as accepted. Welcome to SO!
– tonytonov
Jan 19 '15 at 12:03
43
If you're usingroxygen2, you could add#' importFrom magrittr "%>%"to have NAMESPACE populated automatically duringroxygenize().
– Roman Luštrik
Feb 11 '15 at 15:20
27
@RomanLuštrik, just missing @, should be#' @importFrom magrittr "%>%"
– Roah
Aug 14 '15 at 18:05
7
Note that this will only allow you to use%>%internally in your package. If your API requires users to chain functions using%>%, they will still have to explicitly loadmagrittr. One way to solve this problem is to re-export the function. Here is an example of how to do it.
– Ramnath
Dec 28 '15 at 7:10
1
1
Thanks, that solved the problem.
– alexander keth
Jan 19 '15 at 11:37
Thanks, that solved the problem.
– alexander keth
Jan 19 '15 at 11:37
1
1
@alexanderketh In that case you should hit the green tick mark next to the answer to mark it as accepted. Welcome to SO!
– tonytonov
Jan 19 '15 at 12:03
@alexanderketh In that case you should hit the green tick mark next to the answer to mark it as accepted. Welcome to SO!
– tonytonov
Jan 19 '15 at 12:03
43
43
If you're using
roxygen2, you could add #' importFrom magrittr "%>%" to have NAMESPACE populated automatically during roxygenize().– Roman Luštrik
Feb 11 '15 at 15:20
If you're using
roxygen2, you could add #' importFrom magrittr "%>%" to have NAMESPACE populated automatically during roxygenize().– Roman Luštrik
Feb 11 '15 at 15:20
27
27
@RomanLuštrik, just missing @, should be
#' @importFrom magrittr "%>%"– Roah
Aug 14 '15 at 18:05
@RomanLuštrik, just missing @, should be
#' @importFrom magrittr "%>%"– Roah
Aug 14 '15 at 18:05
7
7
Note that this will only allow you to use
%>% internally in your package. If your API requires users to chain functions using %>%, they will still have to explicitly load magrittr. One way to solve this problem is to re-export the function. Here is an example of how to do it.– Ramnath
Dec 28 '15 at 7:10
Note that this will only allow you to use
%>% internally in your package. If your API requires users to chain functions using %>%, they will still have to explicitly load magrittr. One way to solve this problem is to re-export the function. Here is an example of how to do it.– Ramnath
Dec 28 '15 at 7:10
|
show 1 more comment
One additional solution - use the roxygen package. It's implemented as part of the devtools package. Once devtools is installed, calling devtools::document() will update your NAMESPACE for you. It also auto-builds .Rd files with documentation, which is handy.
All you do is add a special comment in the format #' @import packagename to a file to import all functions from that package, or #' @importFrom packagename functionname to import a function. You can have as many of these comments as you want in your files, so you can have a set of them at the top of each file, or with each of your functions that needs an external function.
Then you run devtools::document() and it parses your code looking for those comments, and then it creates an appropriate NAMESPACE file for you. Easy.
When I do this, it messes up the following oxygen comments that pertain to the help file for the first function in the R script. How do I separate global oxygen comments from the help file ones?
– jzadra
Oct 24 '17 at 21:36
2
I usually put the import comments with each function individually. That way if other functions in the file change, your imports stay accurate. So then there are no global definitions.
– Mike Stanley
Oct 24 '17 at 21:39
add a comment |
One additional solution - use the roxygen package. It's implemented as part of the devtools package. Once devtools is installed, calling devtools::document() will update your NAMESPACE for you. It also auto-builds .Rd files with documentation, which is handy.
All you do is add a special comment in the format #' @import packagename to a file to import all functions from that package, or #' @importFrom packagename functionname to import a function. You can have as many of these comments as you want in your files, so you can have a set of them at the top of each file, or with each of your functions that needs an external function.
Then you run devtools::document() and it parses your code looking for those comments, and then it creates an appropriate NAMESPACE file for you. Easy.
When I do this, it messes up the following oxygen comments that pertain to the help file for the first function in the R script. How do I separate global oxygen comments from the help file ones?
– jzadra
Oct 24 '17 at 21:36
2
I usually put the import comments with each function individually. That way if other functions in the file change, your imports stay accurate. So then there are no global definitions.
– Mike Stanley
Oct 24 '17 at 21:39
add a comment |
One additional solution - use the roxygen package. It's implemented as part of the devtools package. Once devtools is installed, calling devtools::document() will update your NAMESPACE for you. It also auto-builds .Rd files with documentation, which is handy.
All you do is add a special comment in the format #' @import packagename to a file to import all functions from that package, or #' @importFrom packagename functionname to import a function. You can have as many of these comments as you want in your files, so you can have a set of them at the top of each file, or with each of your functions that needs an external function.
Then you run devtools::document() and it parses your code looking for those comments, and then it creates an appropriate NAMESPACE file for you. Easy.
One additional solution - use the roxygen package. It's implemented as part of the devtools package. Once devtools is installed, calling devtools::document() will update your NAMESPACE for you. It also auto-builds .Rd files with documentation, which is handy.
All you do is add a special comment in the format #' @import packagename to a file to import all functions from that package, or #' @importFrom packagename functionname to import a function. You can have as many of these comments as you want in your files, so you can have a set of them at the top of each file, or with each of your functions that needs an external function.
Then you run devtools::document() and it parses your code looking for those comments, and then it creates an appropriate NAMESPACE file for you. Easy.
answered Jan 20 '16 at 15:32
Mike StanleyMike Stanley
94069
94069
When I do this, it messes up the following oxygen comments that pertain to the help file for the first function in the R script. How do I separate global oxygen comments from the help file ones?
– jzadra
Oct 24 '17 at 21:36
2
I usually put the import comments with each function individually. That way if other functions in the file change, your imports stay accurate. So then there are no global definitions.
– Mike Stanley
Oct 24 '17 at 21:39
add a comment |
When I do this, it messes up the following oxygen comments that pertain to the help file for the first function in the R script. How do I separate global oxygen comments from the help file ones?
– jzadra
Oct 24 '17 at 21:36
2
I usually put the import comments with each function individually. That way if other functions in the file change, your imports stay accurate. So then there are no global definitions.
– Mike Stanley
Oct 24 '17 at 21:39
When I do this, it messes up the following oxygen comments that pertain to the help file for the first function in the R script. How do I separate global oxygen comments from the help file ones?
– jzadra
Oct 24 '17 at 21:36
When I do this, it messes up the following oxygen comments that pertain to the help file for the first function in the R script. How do I separate global oxygen comments from the help file ones?
– jzadra
Oct 24 '17 at 21:36
2
2
I usually put the import comments with each function individually. That way if other functions in the file change, your imports stay accurate. So then there are no global definitions.
– Mike Stanley
Oct 24 '17 at 21:39
I usually put the import comments with each function individually. That way if other functions in the file change, your imports stay accurate. So then there are no global definitions.
– Mike Stanley
Oct 24 '17 at 21:39
add a comment |
Assuming that you're using RStudio, Hadley's devtools package, and listed magrittr in the Imports section of the DESCRIPTION file, here are steps I took to make %>% work in my package function(s).
First, write function foo.R:
#' Convert code{data.frame} to code{list}.
#'
#' @importFrom magrittr %>%
#' @name %>%
#' @rdname pipe
#' @export
#' @param x A code{data.frame} object.
#' @examples
#' my_result <- foo(iris)
#'
foo <- function(x) {
x %>%
as.list()
}
Second, run devtools::document().
Third, run devtools::load_all().
A file like this will be created in your R/ directory and your function should work as expected.
3
what is the purpose of@name %>%here?
– Jelena-bioinf
Mar 27 '18 at 14:52
add a comment |
Assuming that you're using RStudio, Hadley's devtools package, and listed magrittr in the Imports section of the DESCRIPTION file, here are steps I took to make %>% work in my package function(s).
First, write function foo.R:
#' Convert code{data.frame} to code{list}.
#'
#' @importFrom magrittr %>%
#' @name %>%
#' @rdname pipe
#' @export
#' @param x A code{data.frame} object.
#' @examples
#' my_result <- foo(iris)
#'
foo <- function(x) {
x %>%
as.list()
}
Second, run devtools::document().
Third, run devtools::load_all().
A file like this will be created in your R/ directory and your function should work as expected.
3
what is the purpose of@name %>%here?
– Jelena-bioinf
Mar 27 '18 at 14:52
add a comment |
Assuming that you're using RStudio, Hadley's devtools package, and listed magrittr in the Imports section of the DESCRIPTION file, here are steps I took to make %>% work in my package function(s).
First, write function foo.R:
#' Convert code{data.frame} to code{list}.
#'
#' @importFrom magrittr %>%
#' @name %>%
#' @rdname pipe
#' @export
#' @param x A code{data.frame} object.
#' @examples
#' my_result <- foo(iris)
#'
foo <- function(x) {
x %>%
as.list()
}
Second, run devtools::document().
Third, run devtools::load_all().
A file like this will be created in your R/ directory and your function should work as expected.
Assuming that you're using RStudio, Hadley's devtools package, and listed magrittr in the Imports section of the DESCRIPTION file, here are steps I took to make %>% work in my package function(s).
First, write function foo.R:
#' Convert code{data.frame} to code{list}.
#'
#' @importFrom magrittr %>%
#' @name %>%
#' @rdname pipe
#' @export
#' @param x A code{data.frame} object.
#' @examples
#' my_result <- foo(iris)
#'
foo <- function(x) {
x %>%
as.list()
}
Second, run devtools::document().
Third, run devtools::load_all().
A file like this will be created in your R/ directory and your function should work as expected.
answered Jan 21 '16 at 17:21
JubblesJubbles
2,04162544
2,04162544
3
what is the purpose of@name %>%here?
– Jelena-bioinf
Mar 27 '18 at 14:52
add a comment |
3
what is the purpose of@name %>%here?
– Jelena-bioinf
Mar 27 '18 at 14:52
3
3
what is the purpose of
@name %>% here?– Jelena-bioinf
Mar 27 '18 at 14:52
what is the purpose of
@name %>% here?– Jelena-bioinf
Mar 27 '18 at 14:52
add a comment |
There's now an easier way to support the pipe in your packages. The wonderful package usethis has the function use_pipe(). You run that function once and it handles everything. This is how the use_pipe() function is described in the usethis documentation:
Does setup necessary to use magrittr's pipe internally in your package
and to re-export it for users of your package:
Adds magrittr to "Imports" in DESCRIPTION
Creates R/utils-pipe.R with the necessary roxygen template
1
I love this way, thanks.
– Shixiang Wang
Jan 7 at 4:28
You're very welcome!
– Andrew Brēza
Feb 4 at 20:05
add a comment |
There's now an easier way to support the pipe in your packages. The wonderful package usethis has the function use_pipe(). You run that function once and it handles everything. This is how the use_pipe() function is described in the usethis documentation:
Does setup necessary to use magrittr's pipe internally in your package
and to re-export it for users of your package:
Adds magrittr to "Imports" in DESCRIPTION
Creates R/utils-pipe.R with the necessary roxygen template
1
I love this way, thanks.
– Shixiang Wang
Jan 7 at 4:28
You're very welcome!
– Andrew Brēza
Feb 4 at 20:05
add a comment |
There's now an easier way to support the pipe in your packages. The wonderful package usethis has the function use_pipe(). You run that function once and it handles everything. This is how the use_pipe() function is described in the usethis documentation:
Does setup necessary to use magrittr's pipe internally in your package
and to re-export it for users of your package:
Adds magrittr to "Imports" in DESCRIPTION
Creates R/utils-pipe.R with the necessary roxygen template
There's now an easier way to support the pipe in your packages. The wonderful package usethis has the function use_pipe(). You run that function once and it handles everything. This is how the use_pipe() function is described in the usethis documentation:
Does setup necessary to use magrittr's pipe internally in your package
and to re-export it for users of your package:
Adds magrittr to "Imports" in DESCRIPTION
Creates R/utils-pipe.R with the necessary roxygen template
answered Sep 8 '18 at 3:06
Andrew BrēzaAndrew Brēza
2,89911628
2,89911628
1
I love this way, thanks.
– Shixiang Wang
Jan 7 at 4:28
You're very welcome!
– Andrew Brēza
Feb 4 at 20:05
add a comment |
1
I love this way, thanks.
– Shixiang Wang
Jan 7 at 4:28
You're very welcome!
– Andrew Brēza
Feb 4 at 20:05
1
1
I love this way, thanks.
– Shixiang Wang
Jan 7 at 4:28
I love this way, thanks.
– Shixiang Wang
Jan 7 at 4:28
You're very welcome!
– Andrew Brēza
Feb 4 at 20:05
You're very welcome!
– Andrew Brēza
Feb 4 at 20:05
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f27947344%2fr-use-magrittr-pipe-operator-in-self-written-package%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
I would advise against the pipe operator inside a function inside a package. It makes debugging a lot harder (the call stack gets insanely deep with the pipe). For packages I'd just overwrite a temporary variable, which makes testing a lot easier (think: R telling you on what line the error occurred). The pipe is fine for interactive use but for programming it can be a burden.
– Mark van der Loo
May 23 '17 at 12:55