Re: [Rd] Fields used by available.packages

2024-06-12 Thread Kurt Hornik
> 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

2024-06-12 Thread Lluís Revilla
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

2024-06-12 Thread Kurt Hornik
> 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