Giters

PUGX / badge-poser

The PHP badges, renders some badges for your readme with the packagist information.

Home Page:https://poser.pugx.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Shields broken after repo was moved

ancarda opened this issue · comments

commented

Bug Report

Summary

I moved my repo from GitHub to SourceHut, and now the shields all show - | -.

Current behavior

All shields show - | -, such as: https://poser.pugx.org/ancarda/psr7-string-stream/downloads

How to reproduce

  1. Create a project on GitHub and Packagist.
  2. Setup badges. Observe they work properly.
  3. Move the project to SourceHut - updating the repo URL on Packagist.
  4. Observe the badges break.

After a few days, the badges have not reset/started working again.

Expected behavior

Badges would continue working correctly, no matter where I move the repo -- as the stats are pulled from Packagist, right?

commented

SourceHut is not supported at the moment by our libraries to retrieve data from the repository.

commented

@AlessandroMinoccheri exactly!
@ancarda we're sorry! Curiosity, why did you decide to migrate your sources?

commented

SourceHut is not supported at the moment by our libraries to retrieve data from the repository

I'm a bit confused by this, doesn't Poser pull statistics from Packagist? In that sense, shouldn't it be completely agnostic?

If not, how does Poser handle self-hosted instances of, e.g. GitLab?

why did you decide to migrate your sources?

I've been unhappy with GitHub for some time. Sadly, many of the popular replacements - GitLab and Gitea - were essentially aiming to be a clone of GitHub. While they do solve the issue with propitiatory proprietary software, they don't do much to fix the other issues with GitHub's design.

I eventually came across SourceHut; which far better resembles the sort of computing I desire - lightweight, fast, as little lock-in as possible, 100% free software, no requirement to use JavaScript, based around email so you don't have to have an account, etc... I'm really quite happy on SourceHut. It's like using Craigslist or old.reddit.com; brutal, harsh design - but it really works and boy is it fast.

I left GitHub mirrors up to not break any URLs to my existing projects. So, I imagine I might cause fewer problems with brand new projects. Moving psr7-string-stream kinda broke Packagist too! 😂

commented

@ancarda we take some data from packagist and others from github and combine them to make badges.
To solve the problem you say, such as packages present on GitLab or Bitbucket, we simply add integration to other possible sources as fallback.
For example we currently support packages on github and bitbucket.
If you want to add support for SourceHut too (if they make bees available), your PR is welcome! ;)

commented

Another benefit of free software is I never risk misspelling "proprietary"! 😂 Which for some reason is a word I struggle to spell properly all the time.

commented

Haven't seen code this clean and readable for some time! It'll be easy to add support for SourceHut.

Though, I can't shake the feeling that adding support for specific hosting providers isn't the right thing to do. Ideally someone who self-hosts SourceHut, Gitea, GitLab, and so on should be able to use tools like Poser too.

It's difficult to fix this, but I posted an idea for a possible way to bridge the gap. Either way, leave this with me -- I'll add support for SourceHut one way or the other.

commented

This still seems to be an issue with code hosted on gitlab.

I could understand that some badges don't work with other services than github. But the latest version, and espechially the download numbers are plainly taken from packagist and should at least work independent from the service hosting the public repo.

I'll see to find a way around that. Expect a PR at one point ;-)

commented

@heiglandreas have you already started doing the PR?
I can try to work on GitLab client for missed badges.

commented

I was just going to start to check what's going on 😁

Had to fix some other issues first. So feel free to go ahead. Though I would have approached the whole issue to check where individual access would be necessary in the first place and tried to make it as independent as possible so that different clients might not be necessary any more...

But perhaps we can tackle the issue from two sides 😉 So feel free to go for the GitLab client!

commented

It makes sense for me, I try to work with the GitLab client and the next step could be yours about being independent for clients if it's possible 😁

commented

Absolutely! The for me annoying point is that the Repo-CLient (Github/Bitbucket/Gitlab et al) is only relevant for the composer.lock and the gitattributes badge. All others could live without that but still require it...

I might start with separating that 😉

commented

@heiglandreas do you have an example of a public repository on GitLab and packagist to test?