Store package metadata somewhere

[goodmami]

LMF Packages and Collections can have metadata files like README, LICENSE, and citation.bib, but these are not stored in the database. For downloaded files, they will persist in the cache, but the cache is not meant to be a permanent record. Putting big text blobs in the database doesn't seem ideal, either. I'm not sure we even want to store these locally

We could create another data subdirectory for these. Something like .wn_data/project_meta. This might contain package directories with everything but the resource files.

[goodmami]

The easiest solution here is probably to just put them in the database rather than doing something custom. If we're just creating a new table and not modifying an existing one, we can add it without forcing users to rebuild their databases, however they wouldn't have access to the metadata of lexicons inserted before the feature is added.

We could probably have a table for READMEs, one for LICENSEs, and another for citation.bibs. E.g.,

CREATE TABLE IF NOT EXISTS licenses (
    lexicon_rowid INTEGER NOT NULL REFERENCES lexicons(rowid) ON DELETE CASCADE,
    text TEXT
)

[fcbond]

This seems like a good solution, and I think they are not so big, so should not increase the size much.

…

On Sat, Nov 6, 2021 at 12:41 AM Michael Wayne Goodman < ***@***.***> wrote: The easiest solution here is probably to just put them in the database rather than doing something custom. If we're just creating a new table and not modifying an existing one, we can add it without forcing users to rebuild their databases, however they wouldn't have access to the metadata of lexicons inserted before the feature is added. We could probably have a table for READMEs, one for LICENSEs, and another for citation.bibs. E.g., CREATE TABLE IF NOT EXISTS licenses ( lexicon_rowid INTEGER NOT NULL REFERENCES lexicons(rowid) ON DELETE CASCADE, text TEXT ) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIPZRQXV3HXUMKSOHVFLGDUKQJLZANCNFSM4T4NQG4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Francis Bond <http://www3.ntu.edu.sg/home/fcbond/> Division of Linguistics and Multilingual Studies Nanyang Technological University

[goodmami]

More thoughts: this probably shouldn't be stored in the DB. The DB contains information in lexicons, but the readmes, licenses, and citations are from separate files. Furthermore, a resource file can have multiple lexicons, so the other files may pertain to multiple lexicons.

I now think this information should be modeled by projects. Unfortunately, Wn has two views of projects. The wn.projects() function lists information from the index.toml file, while wn.project.iterpackages() yields Package objects (which have readme() and similar methods). If there were something like wn.project.get_project(path_or_specifier) that got the Package for some local or downloaded and cached package, then we would have access to the package metadata for a given project.