DrewNaylor
A possible way to get manifest details using the SQLite database file.
I'd like it to be so that the SQLite database is read for package ID and version, and afterward look for a manifest in the local cache with that ID and version. Opening each manifest to check ID and version may be the fastest way to reliably do this, which will ensure we don't run into an issue where a package ID has a dot where it shouldn't.
If a source such as the Store source doesn't have an easily-accessible manifest zip file, something else that could be done is to run winget source update, then once it's done run winget show (PackageID) -v (PackageVersion) and use this output for the package details textbox. This output could also be used for the Description column until next application start, though that will probably require text interpretation like seeing where there's "Description: " preceded by a CrLf (since it would be a good idea to turn all Cr and Lf characters into CrLf to make things easier) and take the substring until the first CrLf (we're going to replace the other characters as I said before).
(Copied from #34)
Maybe it would help to store the row number for each entry in the ids.id column so that we know what the index is when looking up the version numbers. Only problem is I don't know if that would be guaranteed to work correctly since there's the manifest table, which I don't understand why Microsoft didn't just put some of the data in that table directly. Would have made this so much easier.
Starting from this page seems good: https://www.sqlitetutorial.net/sqlite-select/
Joining tables may help: https://www.sqlitetutorial.net/sqlite-join/
Initial support for this is mostly finished, but it may be a good idea to move the code that gets manifest details into the If...Else block that gets info from manifests so that it's not in the post-update code.
This issue may as well be closed, but the part about getting details for sources without easily-accessible manifests is still important.
Besides this comment here https://github.com/DrewNaylor/guinget/issues/35#issuecomment-683642744 needing to be added if it isn't already, stability and bug fixes need to be added to ensure the database can update if its temp folder exists and the manifest temp folder doesn't. Right now, the code that checks whether the temp folders exist assume that if one exists, so does the other one, when that's not necessarily the case. Separating these If/Else code blocks would make it more reliable and be usable as a non-experimental feature.
Now the database can update if its temp folder exists and the manifests temp folder doesn't. As stated in 6a38d93, this will eventually allow updating multiple sources based on what's in a YAML file, but that's not quite ready yet. Realistically this should allow the database-updating feature to move out of the "Experimental" tab in version 0.2 or 0.2.1.
Still some things that need this issue to stay open, like "the part about getting details for sources without easily-accessible manifests".
The Store uses REST now, though. Hmmmm... This still needs to be open due to the fact that some sources besides the Store might not offer an easy way to get manifests, anyway, even if they don't use REST.