fix: packages starts count

[ArtemkaKun]

Fixes #47

This PR implements 2 things for now:

• allow the admin (test_user) to submit packages for GitHub repos they doesn't manage.
• adding stars count to the newly added package.

Problem

The problem is not trivial, however.

Currently, 3 problems with starts need to be addressed:

1. Stars count for newly added packages
2. Stars count for already existing packages
3. Handling stars count change in realtime

Solution

One way to resolve the issue - on start, VPM can iterate over all packages currently in DB and do 2 things:

1. Fetch the current stars count from GitHub and update data in DB
2. Subscribe on event/webhook for stars count update

This will add some time to the VPM start time (probably if we split requests on different processes it will go faster).

Also, when the user adds a new package to VPM, it needs to subscribe on event/webhook for the stars count update for this repo as well.

In this way, we will have a good user experience, up-to-date starts count data (without migration for old packages required), and will no exceed the GitHub API rate limit.

[Casper64]

Since the star counts are in the database, can’t they be fetched by a separate script that updates the database on a webhook/every day? No time is added at start up of vpm but it’s actually reduced and the logic is seperated.

Imo star fetching isn’t part of the vpm app but should be separate logic.

When a user submits a new package the fetch script can be called and the database is updated.

[ArtemkaKun]

@Casper64

I see 2 problems with your proposition:

1. Managing external scripts/services can be challenging and can add additional overhead to project setup, maintenance, and codebase. Since VPM code already knows about packages, DB, and has GitHub API implemented, I see only one benefit from creating a microservice, that will manage only stars count - it's logic separation, as you said, and nothing more.
2. I'm not sure if we need to keep the starts count up-to-date in realtime, but updating once per day seems too rare to me. Webhooks will deal with that problem, but right now Idk how they works and how much time we need to implement them for GitHub API

[ArtemkaKun]

Ok, seems there is no webhook from GitHub that will rise an event when a particular repository was starred. We should manually check star changes :/

[ArtemkaKun]

And rate limit will come into play then https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting

[Casper64]

I went on google to look how other package managers do it (npm pub.dev cargo etc.). None of them have github star count, but their own "like" counter. Wouldn't that be a better solution? Solves a lot of headaches

[ArtemkaKun]

It should be easier I think. On the other hand, I think people will be more active on GitHub, then on VPM. @medvednikov how stars feature should work?

[ghost]

I think stars should be in VPM because there are two problems:

1. Synchronizing stars, as you mentioned.
2. Dependency on GitHub. However, we need to consider adding support for other hosting platforms such as GitLab, Gitly, Gitea, etc., which may not have a stars feature, or we would need to utilize the API of each platform.

[ghost]

It would be nice to use hosting platforms only for hosting Git repositories and nothing more. All other features should be implemented within VPM.

[medvednikov]

Indeed, github is not going to be the only site we support. So we should just have our own stars.

[ArtemkaKun]

Ok, I improved issue description and will close this PR since changes here have no sense anymore