Consider exporting `read_pkglite()`

[nanxstats]

It feels like it would generate more benefits than harms if we make read_pkglite() an exported function, because people might need to parse pkglite.txt directly sometimes. This would avoid the use of :::.

What do you think? @elong0527

[elong0527]

agree 👍

[nanxstats]

I think if we export read_pkglite(), it's reasonable to also create and export a new function write_pkglite() by decoupling the middle part from unpack(). This means that you can read it from the txt, work on the list, and write it back.

Update: oops, unpack() only writes to package structures so it's irrelevant. We only need to create the logic to write the list to txt. A typical user flow can be pack() -> read_pkglite() -> modify list or just get some data -> write_pkglite() or not -> unpack().

To show this visually:

userflow.drawio.txt

We should extend the format.Rmd vignette to explain this (APIs for working with the txt) and include the above chart.