element of class package_version causes error

[vjcitn]

> library(alabaster.base)
1/9 packages newly attached/loaded, see sessionInfo() for details.
> x = list(a=1)
> saveObject(x, "/tmp/fgh")  # all good
> y = list(a=packageVersion("alabaster.base"))
> saveObject(y, "/tmp/ghi")
Error in value[[3L]](cond) : failed to stage list element 'a'
  - failed to stage list element 1
  - failed to stage list element 1
  - failed to stage list element 1
...

R version 4.4.2 (2024-10-31)
Platform: aarch64-apple-darwin20
Running under: macOS Sequoia 15.2

Matrix products: default
BLAS:   /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRblas.0.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/New_York
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] alabaster.base_1.6.1 rmarkdown_2.29      

loaded via a namespace (and not attached):
 [1] digest_0.6.37           fastmap_1.2.0           xfun_0.50              
 [4] knitr_1.49              rhdf5filters_1.18.0     BiocGenerics_0.52.0    
 [7] htmltools_0.5.8.1       stats4_4.4.2            Rhdf5lib_1.28.0        
[10] cli_3.6.3               rhdf5_2.50.2            compiler_4.4.2         
[13] tools_4.4.2             evaluate_1.0.3          alabaster.schemas_1.6.0
[16] startup_0.23.0          Rcpp_1.0.14             jsonlite_1.8.9         
[19] S4Vectors_0.44.0        rlang_1.1.5  

Noted with alabaster.sfe @lambdamoses

[LTLA]

Not the first time this has been reported, though I can't remember where the first one was. At the time I couldn't make up my mind on what to do.

I suppose we should just coerce package_versions to plain strings for simplicity. Seems rather onerous to write out a new spec for package version strings; we did so for date and date-times, but with hindsight, that added a moderate amount of complexity for no benefit. Users didn't really care that the dates were represented as strings rather than POSIXt objects, and I'll bet that would be the case for package versions as well.

[vjcitn]

I understand the sentiment but I think this is a slippery slope. Clearly you have no obligation to fix it but these concepts have status in at least one language and if we can mobilize some effort to do these right, IMHO it should be done. Given the hint that examples exist in the date space, I'd like to discuss this at the next TAB meeting to see if someone has bandwidth to address this.

[LTLA]

This is more effort than you might think. A new version format would need to be added to:

• string arrays in lists.
• string arrays in columns.
• free-standing string arrays.

Then, one would have to decide on what a version string actually is. For example, Python will happily support stuff like packaging.version.Version("1.0.0rc1") while R refuses to consider it:

package_version("1.0.0rc1")
## Error: invalid version specification ‘1.0.0rc1’

R also converts all version strings to use dot separators, which could be problematic if the dash has some meaning:

# Is this desirable?
identical(package_version("1.2-3.4"), package_version("1.2.3-4"))
## [1] TRUE

If we want to provide a portable and stable version type, we would have to keep it a string instead of automatically converting it to R's package_version class. That's a lot of effort to provide little benefit to the user if they have to deal with a string anyway.

Better to just save it as a string, and if SFE really needs it to be a package_version, the reader method for SFEs should be responsible for handling the coercion. We don't guarantee 100% roundtrips anyway - for example, data.frames get converted to DataFrames after one save/read cycle - and especially not for random stuff in metadata(). Some language-specific information is bound to be lost when converting to a language-agnostic format.

As a historical note, you can see the aftereffects of a similar effort with respect to RFC3339-formatted date-times. These can't be reliably converted to POSIXt objects as (i) I could never figure out how to preserve the timezone and (ii) fractional seconds could not be faithfully represented in double-precision. In the end, I just kept these dates in a character vector with the Rfc3339 class and people have to convert them to POSIXt as needed. In hindsight, it would have been better to represent them as strings to avoid confusing users with a weird class.

[LTLA]

In the meantime, #31 should fix the immediate problem.