Add option to run checkpoint() without scanning for packages

[andrie]

Use case: In production environments the consideration of performance might be important. So if the user can make the explicit assumption that all required packages are already available in the .checkpoint folder, then checkpoint() can skip scanning and installing packages, and simply set the library paths, etc.

Possible implementation:

checkpoint(..., scanForPackages = TRUE)

[Philipp-Neubauer]

May I suggest one more level of flexibility - i.e., rather than just a scanForPackages, have a packages option with default checkpoint(..., packages = all) which leads to the default scan behaviour, and options to specify a vector of package names to manually dictate the package list or say packages = none for the behaviour suggested above.

[piccolbo]

Interesting but the list option is equivalent to

checkpoint(..., packages = none)
install.packages(package.list)

What's wrong with this approach? Do we need a new feature to avoid the
second line? Unless I am missing something.

On Mon, Feb 9, 2015 at 6:00 PM, Philipp Neubauer notifications@github.com
wrote:

May I suggest one more level of flexibility - i.e., rather than just a
scanForPackages, have a packages option with default checkpoint(...,
packages = all) which leads to the default scan behaviour, and options to
specify a vector of package names to manually dictate the package list or
say packages = none for the behaviour suggested above.

—
Reply to this email directly or view it on GitHub
#162 (comment)
.

[Philipp-Neubauer]

true, that should do the same. So probably not necessary after-all. Perhaps
it's just a bit nicer in terms of syntax, since it explicitly states that
those packages are installed into the checkpoint library, which may not
always be as obvious if the second line is somewhere else in a script, or
even scattered across multiple install.packages() as the code
progresses. But then again, I suppose you could just call that bad
practice, and encourage users to put the second line with a complete list
at the of a script along checkpoint()

On Tue, Feb 10, 2015 at 6:32 PM, Antonio Piccolboni <
notifications@github.com> wrote:

Interesting but the list option is equivalent to

checkpoint(..., packages = none)
install.packages(package.list)

What's wrong with this approach? Do we need a new feature to avoid the
second line? Unless I am missing something.

On Mon, Feb 9, 2015 at 6:00 PM, Philipp Neubauer <notifications@github.com

wrote:

May I suggest one more level of flexibility - i.e., rather than just a
scanForPackages, have a packages option with default checkpoint(...,
packages = all) which leads to the default scan behaviour, and options to
specify a vector of package names to manually dictate the package list or
say packages = none for the behaviour suggested above.

—
Reply to this email directly or view it on GitHub
<
#162 (comment)

.

—
Reply to this email directly or view it on GitHub
#162 (comment)
.

Phil

[piccolbo]

On Tue, Feb 10, 2015 at 12:54 PM, Philipp Neubauer <notifications@github.com

wrote:

true, that should do the same. So probably not necessary after-all. Perhaps
it's just a bit nicer in terms of syntax, since it explicitly states that
those packages are installed into the checkpoint library, which may not
always be as obvious if the second line is somewhere else in a script, or
even scattered across multiple install.packages() as the code
progresses. But then again, I suppose you could just call that bad
practice, and encourage users to put the second line with a complete list
at the of a script along checkpoint()

And you wouldn't be able to enforce good practices by adding that option
anyway. We use the underlying R mechanism for libraries and repos which
tampers with the global state of the interpreter, creating those long
distance, dynamically determined interactions you describe. I suspect we
feel exactly the same about how dangerous they are, but R is not purely
functional and that's not something that can be changed in a package.

packages = all) which leads to the default scan behaviour, and options
to

specify a vector of package names to manually dictate the package list
or
say packages = none for the behaviour suggested above.

—
Reply to this email directly or view it on GitHub
<

#162 (comment)

.

—
Reply to this email directly or view it on GitHub
<
#162 (comment)

.

Phil

—
Reply to this email directly or view it on GitHub
#162 (comment)
.

[andrie]

So, for now, I'm delaying (ignoring) the additional feature request. I plan to only implement checkpoint(..., scanForPackages = TRUE) in the next release.

I'll open a new issue #168 to reflect the remaining, unresolved part of this discussion.