Done... -pd
> On 11 Oct 2022, at 10:53 , peter dalgaard wrote:
>
> There's still 2 weeks till code freeze for 4.2.2, and porting the fix would
> be trivial. As long as there is no risk that someone will get the bright idea
> of changing a critical package to depend on R >= 4.2.2...
>
> - pd
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
I think '[.POSIXlt' and '[<-.POSIXlt' don't need to normalize out-of-range
values. I think they just make same length for all components, to ensure
correct extraction or replacement for arbitrary index.
I have a thought of adding an optional argument for 'as.POSIXlt' applied to
"POSIXlt" object
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
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
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
