On 08/11/2019 2:06 a.m., Joshua Bradley wrote:
Hello,
Currently if you install a package twice:
install.packages("testit")
install.packages("testit")
R will build the package from source (depending on what OS you're using)
twice by default. This becomes especially burdensome when people are us
I could do this...and I have before. This brings up a more fundamental
question though. You're asking me to write code that changes the logic of
the installation process (i.e. writing my own package installer). Instead
of doing that, I would rather integrate that logic into R itself to improve
the
While developing a package, I often run install.packages() on it many times
in a session without updating its version number. How would your proposed
change affect this workflow?
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Nov 8, 2019 at 11:56 AM Joshua Bradley wrote:
> I could do thi
Since we are on this topic, another area of improvement is when
install.packages() downloads hundreds of packages only to realize later
that many of them actually fail to install because one of the packages
they depend on (directly or indirectly) failed to install.
Cheers,
H.
On 11/8/19 11:55
I guess you would just use force=TRUE
H.
On 11/8/19 12:06, William Dunlap via R-devel wrote:
> While developing a package, I often run install.packages() on it many times
> in a session without updating its version number. How would your proposed
> change affect this workflow?
> Bill Dunlap
> TI
Exactly. Every major commit isn’t want to check that the package works.
Also, besides package development, there are other reasons why one would
install packages over themselves. For example, rebuilding from source after
changing options in Makevars[.win]. The package hasn’t been updated but
recom
Hi Josh,
There are a few issues I can think of with this. The primary one is that
CRAN(/Bioconductor) is not the only place one can install packages from. I
might have version x.y.z of a package installed that was, at the time, a
development version I got from github, or installed locally, etc. He
On 08/11/2019 2:55 p.m., Joshua Bradley wrote:
I could do this...and I have before. This brings up a more fundamental
question though. You're asking me to write code that changes the logic of
the installation process (i.e. writing my own package installer). Instead
of doing that, I would rather i
Suppose update.packages("pkg") installed "pkg" if it were not already
installed, in addition to its current behavior of installing "pkg" if "pkg"
is installed but a newer version is available. The OP could then use
update.packages() all the time instead of install.packages() the first time
and upd
Hi Gabe,
Keeping track of where a package was installed from would be a nice
feature. However it wouldn't be as reliable as comparing hashes to
decide whether a package needs re-installation or not.
H.
On 11/8/19 12:37, Gabriel Becker wrote:
> Hi Josh,
>
> There are a few issues I can think o
On 08/11/2019 6:02 p.m., William Dunlap wrote:
Suppose update.packages("pkg") installed "pkg" if it were not already
installed, in addition to its current behavior of installing "pkg" if
"pkg" is installed but a newer version is available. The OP could then
use update.packages() all the time i
I believe introducing a backward compatible force=TRUE is a good
start, even if we're not ready for making force=FALSE the default at
this point. It would help simplify quite-common instructions like:
if (requireNamespace("BiocManager"))
install.packages("BiocManager")
BiocManager::install(...)
Actually there is one gotcha here: even if a package has not changed
(i.e. same exact hash), there are situations where you want to reinstall
it because one package it depends on has changed. This is because some
of the stuff that gets cached at installation time (e.g. method table)
can become
Sounds a very reasonable approach to me.
H.
On 11/8/19 15:17, Henrik Bengtsson wrote:
> I believe introducing a backward compatible force=TRUE is a good
> start, even if we're not ready for making force=FALSE the default at
> this point. It would help simplify quite-common instructions like:
>
On 08/11/2019 6:17 p.m., Henrik Bengtsson wrote:
I believe introducing a backward compatible force=TRUE is a good
start, even if we're not ready for making force=FALSE the default at
this point. It would help simplify quite-common instructions like
if (requireNamespace("BiocManager"))
instal
Just to clarify the expected behavior I had in mind when proposing the
force argument.
force = T would mean you will "force" an install no matter what (aligns
with the current behavior of the command)
force = F means install a package if it is not found in the local R library
on your system. If i
16 matches
Mail list logo
