[Rd] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

>>>>> Dirk Eddelbuettel writes:

> Hi Kurt,

> On 25 April 2024 at 08:07, Kurt Hornik wrote:
> | >>>>> Hervé Pagès writes:
> | 
> | > Hi Kurt,
> | > Is it intended that numeric_version() returns an error by default on
> | > non-character input in R 4.4.0? 
> | 
> | Dear Herve, yes, that's the intention.
> | 
> | > It seems that I can turn this into a warning by setting
> | > _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
> | > seem to be able to find any of this mentioned in the NEWS file.
> | 
> | That's what I added for smoothing the transition: it will be removed
> | from the trunk shortly.

> I would actually be nice to have a more robust variant for non-CRAN
> versions. For example I just had to do a local hack to be able to use
> what the QuantLib 'rc' 1.34-rc reported (when I then used to R
> facilities to condition code and tests on whether I was dealing with
> code before or after an API transition).  So as a wishlist: could you
> envision an extension to package_version() casting that, say, removes
> all [a-zA-Z]+ first (if opted into) ?

Well, if I could turn back time and start again, I'd implement package
versions in the Debian way, and not numeric only.  As you know, the
current approach does not conveniently allow for handling binary
revisions or NMUs.

Currently, package_version extends numeric_version, but in principle
that could be changed: we would of course have to ensure that we go on
using numeric-only package versions for source packages so that older
versions of R can handle these.

One could in principle also enhance the 'strict' argument so that
e.g. strict = NA says drop all non-numeric non-sep parts, but it would
be better to first figure out whether it wouldn't be better to make
things work for non-numeric version components too :-)

Best
-k



> Dirk

> -- 
> dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org