Hello all,
Following up on this old thread as I have recently observed, rather a
bad practice (maintaining order of installation for R packages rather
than relying on R for that), for solving a problem that R branch
tools4pkgs (mentioned in this email) addresses very well.
More details can be foun
Thank you Gabriel,
Just for future readers. Below is a base R way to address this common
problem, as instructed by you (+stopifnot to suppress print).
Rscript -e 'stopifnot(file.copy("DESCRIPTION",
file.path(tdir<-tempdir(), "PACKAGES")));
db<-available.packages(paste0("file://", tdir));
install.
Hi Jan,
On Fri, Oct 28, 2022 at 1:57 PM Jan Gorecki wrote:
> Gabriel,
>
> It is the most basic CI use case. One wants to install only
> dependencies only of the package, and run R CMD check on the package.
Really what you're looking for though, is to install all the dependencies
which aren't
Gabriel,
It is the most basic CI use case. One wants to install only
dependencies only of the package, and run R CMD check on the package.
Unless you say that installing the package and then running R CMD
check on that package is considered good practice. Then yes,
functionality I am asking about
Hi Jan,
The reason, I suspect without speaking for R-core, is that by design you
should not be specifying package dependencies as additional packages to
install. install.packages already does this for you, as it did in the
construct of a repository code that I provided previously in the thread.
Yo
Gabriel,
I am trying to design generic solution that could be applied to
arbitrary package. Therefore I went with the latter solution you
proposed.
If we wouldn't have to exclude base packages, then its a 3 liner
file.copy("DESCRIPTION", file.path(tdir<-tempdir(), "PACKAGES"));
db<-available.pack
Gabriel and Simon
I completely agree with what you are saying.
The thing is that obtaining recursive deps, all/most whatever, is already
well supported in core R. What is missing is just this single functionality
I am requesting.
If you will look into the branch you can see there is mirror.packag
Jan,
I think using a single DCF as input is not very practical and would not be
useful in the context you describe (creating self contained repos) since they
typically concern a list of packages, but essentially splitting out the part of
install.packages() which determines which files will be
On Fri, Oct 14, 2022 at 11:14 PM Jan Gorecki wrote:
> Hi Gabriel,
>
> It's very nice usage you provided here. Maybe instead of adding new
> function we could extend packages_depenedncies then? To accept file path to
> dsc file.
>
> What about repos.dcf? Maybe additional repositories could be an a
Hi Gabriel,
It's very nice usage you provided here. Maybe instead of adding new
function we could extend packages_depenedncies then? To accept file path to
dsc file.
What about repos.dcf? Maybe additional repositories could be an attribute
attached to returned character vector.
The use case is t
Hi Jan and Jan,
Can you explain a little more what exactly you want the non-recursive,
non-version aware dependencies from an individual package for?
Either way package_dependencies will do this for you* with a little
"aggressive convincing". It wants output from available.packages, but who
reall
Hello Jan,
Thanks for confirming about many packages reinventing this missing
functionality.
packages.dcf was not meant handle versions. It just extracts names of
dependencies... Yes, such a simple thing, yet missing in base R.
Versions of packages can be controlled when setting up R pkgs repo. T
Hello Jan,
I have seen many packages that implemented dependencies "extraction" on
their own for internal purposes and today I was doing exactly that for
mine. It's not a big deal using read.dcf on DESCRIPTION. It was sufficient
for me, but I had to take care of some \n chars (the overall returned
13 matches
Mail list logo
