Re: [Rd] Fields used by available.packages
> Lluís Revilla writes:
> Yes, I think that would be enough.
Thanks. And of course add documentation ...
Will try to get this in in the next few days.
Best
-k
> Thank you, Kurt!
> Lluís
> On Wed, 12 Jun 2024 at 16:35, Kurt Hornik wrote:
>> Lluís Revilla writes:
> Lluis,
> So in available.packages() I could replace
> if (is.null(fields))
> fields <- requiredFields
> else {
> stopifnot(is.character(fields))
> fields <- unique(c(requiredFields, fields))
> }
> by someting like
> if(is.null(fields))
> fields <- getOption("available_packages_fields")
> if(is.null(fields))
> fields <- requiredFields
> else {
> stopifnot(is.character(fields))
> fields <- unique(c(requiredFields, fields))
> }
> ?
> Best
> -k
>> Hi all,
>> I have recently been researching how available.packages and
>> install.packages filter packages from repositories with additional
> fields
>> in their PACKAGES file.
>> Currently there are some default filters, but users (and R admins) can
> set
>> up their own filters by passing a list to the fields argument or adding
>> them to the "available_packages_filters" option.
>> But if the fields used by the filters are not read by default, then
> users
>> must manually add the required fields to each call to
> available.packages.
>> This makes it difficult to use new fields and to control what is
> installed
>> in highly regulated systems which want to use more fields to select
> what is
>> installed.
>> Current workarounds considered are:
>> 1) The filtering function requiring new fields intercepts the call to
>> available.packages and adds the desired fields via eval in
>> parent.environment and then adds the filters again.
>> 2) Import new data (remote or local) when filtering packages, merge
> them
>> and filter accordingly.
>> 3) Suggestions?
>> The first solution is complicated, while the second doesn't use the R
>> machinery of tools::write_PACKAGES to set up the repository with all
> the
>> fields (although how to add more fields to the repository file is a
>> different issue).
>> Would it be possible to add a new option to add fields to be read by
>> available.packages, similar to filters?
>> The same approach for fields as for filters would avoid the two
> workarounds
>> mentioned. To match it, the new option could be named
>> "available_packages_fields".
>> I look forward to hearing from you,
>> Lluís
>> [[alternative HTML version deleted]]
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fields used by available.packages
Yes, I think that would be enough.
Thank you, Kurt!
Lluís
On Wed, 12 Jun 2024 at 16:35, Kurt Hornik wrote:
> > Lluís Revilla writes:
>
> Lluis,
>
> So in available.packages() I could replace
>
> if (is.null(fields))
> fields <- requiredFields
> else {
> stopifnot(is.character(fields))
> fields <- unique(c(requiredFields, fields))
> }
>
> by someting like
>
> if(is.null(fields))
> fields <- getOption("available_packages_fields")
> if(is.null(fields))
> fields <- requiredFields
> else {
> stopifnot(is.character(fields))
> fields <- unique(c(requiredFields, fields))
> }
>
> ?
>
> Best
> -k
>
>
>
> > Hi all,
> > I have recently been researching how available.packages and
> > install.packages filter packages from repositories with additional fields
> > in their PACKAGES file.
>
> > Currently there are some default filters, but users (and R admins) can
> set
> > up their own filters by passing a list to the fields argument or adding
> > them to the "available_packages_filters" option.
> > But if the fields used by the filters are not read by default, then users
> > must manually add the required fields to each call to available.packages.
>
> > This makes it difficult to use new fields and to control what is
> installed
> > in highly regulated systems which want to use more fields to select what
> is
> > installed.
>
> > Current workarounds considered are:
> > 1) The filtering function requiring new fields intercepts the call to
> > available.packages and adds the desired fields via eval in
> > parent.environment and then adds the filters again.
> > 2) Import new data (remote or local) when filtering packages, merge them
> > and filter accordingly.
> > 3) Suggestions?
>
> > The first solution is complicated, while the second doesn't use the R
> > machinery of tools::write_PACKAGES to set up the repository with all the
> > fields (although how to add more fields to the repository file is a
> > different issue).
>
> > Would it be possible to add a new option to add fields to be read by
> > available.packages, similar to filters?
> > The same approach for fields as for filters would avoid the two
> workarounds
> > mentioned. To match it, the new option could be named
> > "available_packages_fields".
>
> > I look forward to hearing from you,
>
> > Lluís
>
> > [[alternative HTML version deleted]]
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fields used by available.packages
> Lluís Revilla writes:
Lluis,
So in available.packages() I could replace
if (is.null(fields))
fields <- requiredFields
else {
stopifnot(is.character(fields))
fields <- unique(c(requiredFields, fields))
}
by someting like
if(is.null(fields))
fields <- getOption("available_packages_fields")
if(is.null(fields))
fields <- requiredFields
else {
stopifnot(is.character(fields))
fields <- unique(c(requiredFields, fields))
}
?
Best
-k
> Hi all,
> I have recently been researching how available.packages and
> install.packages filter packages from repositories with additional fields
> in their PACKAGES file.
> Currently there are some default filters, but users (and R admins) can set
> up their own filters by passing a list to the fields argument or adding
> them to the "available_packages_filters" option.
> But if the fields used by the filters are not read by default, then users
> must manually add the required fields to each call to available.packages.
> This makes it difficult to use new fields and to control what is installed
> in highly regulated systems which want to use more fields to select what is
> installed.
> Current workarounds considered are:
> 1) The filtering function requiring new fields intercepts the call to
> available.packages and adds the desired fields via eval in
> parent.environment and then adds the filters again.
> 2) Import new data (remote or local) when filtering packages, merge them
> and filter accordingly.
> 3) Suggestions?
> The first solution is complicated, while the second doesn't use the R
> machinery of tools::write_PACKAGES to set up the repository with all the
> fields (although how to add more fields to the repository file is a
> different issue).
> Would it be possible to add a new option to add fields to be read by
> available.packages, similar to filters?
> The same approach for fields as for filters would avoid the two workarounds
> mentioned. To match it, the new option could be named
> "available_packages_fields".
> I look forward to hearing from you,
> Lluís
> [[alternative HTML version deleted]]
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fields used by available.packages
Hi all, I have recently been researching how available.packages and install.packages filter packages from repositories with additional fields in their PACKAGES file. Currently there are some default filters, but users (and R admins) can set up their own filters by passing a list to the fields argument or adding them to the "available_packages_filters" option. But if the fields used by the filters are not read by default, then users must manually add the required fields to each call to available.packages. This makes it difficult to use new fields and to control what is installed in highly regulated systems which want to use more fields to select what is installed. Current workarounds considered are: 1) The filtering function requiring new fields intercepts the call to available.packages and adds the desired fields via eval in parent.environment and then adds the filters again. 2) Import new data (remote or local) when filtering packages, merge them and filter accordingly. 3) Suggestions? The first solution is complicated, while the second doesn't use the R machinery of tools::write_PACKAGES to set up the repository with all the fields (although how to add more fields to the repository file is a different issue). Would it be possible to add a new option to add fields to be read by available.packages, similar to filters? The same approach for fields as for filters would avoid the two workarounds mentioned. To match it, the new option could be named "available_packages_fields". I look forward to hearing from you, Lluís [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
