search

webxdc / store

XDC store, migrated to codeberg
https://codeberg.org/webxdc/store
5 stars 0 forks source link

chore: `sources.lock` based imports #161

Closed Septias closed 1 year ago

Septias commented 1 year ago

We had a discussion in the internal xdcstore delta chat group where @hpk42 proposed using a sources.ini file as a single configuration-like file that acts as a single source of truth for the bot. This file is already generated by xdcget and contains the metadata for all the webxdcs. Using this format would allow us to keep the xdc manifests untouched so the developers don't have to create the app_id and version fields. We think that's a great benefit. Also, deleting could be made very explicit by just adding a field removed=true or similar. Making this file mandatory for every webxdc import generates a need for some tooling (be it xdcget or a self-built tool) because adding one single xdc is easy but for more xdcs which is not an uncommon use case for a store it is tiresome to add them manually. Even though this extra need is introduced we decided to go for this new approach.

hpk42 commented 1 year ago

We had a discussion in the internal xdcstore delta chat group where @hpk42 proposed using a sources.ini file as a single configuration-like file that acts as a single source of truth for the bot. This file is already generated by xdcget and contains the metadata for all the webxdcs. Using this format would allow us to keep the xdc manifests untouched so the developers don't have to create the app_id and version fields. We think that's a great benefit. Also, deleting could be made very explicit by just adding a field removed=true or similar.

To clarify: sources.lock is the file that is generated by xdcget, by reading reading the sources.ini and xdcget.ini files and querying github/codeberg release APIs.

And this sources.lock contains "app-id" and "version" but right now these files are also put into the "manifest.toml" of each xdc file.

Making this file mandatory for every webxdc import generates a need for some tooling (be it xdcget or a self-built tool) because adding one single xdc is easy but for more xdcs which is not an uncommon use case for a store it is tiresome to add them manually. Even though this extra need is introduced we decided to go for this new approach.

thanks for writing this down -- let's first get other things finished and maybe head for this change after a bit more IRL discussion and after other things are settled.