Revert "Deprecate HackageDeps service (#10618)"

[sorki]

This reverts commit 04f4fbd156b1b710acbdc4370fe47e4f4b2222a9.

The service is fully functional again and updated regularly, restoring the removal from #10618

[github-actions[bot]]

	Warnings
:warning:	This PR modified service code. Please run tests by including affected services in the pull request title.

	Messages
:book:	:sparkles: Thanks for your contribution to Shields, @sorki!

Generated by :no_entry_sign: dangerJS against d7803110948099561f5af745cef770601d5a8430

[PyvesB]

Hello @sorki 👋🏻

The service is fully functional again and updated regularly

Do you have more details on this?

[sorki]

Hello @sorki 👋🏻

The service is fully functional again and updated regularly

Do you have more details on this?

Hey @PyvesB,

there used to be a deprecation on the front page notice for couple of months which is no longer the case and you can also see Database last updated on the bottom reflecting daily updates.

[PyvesB]

I'm little hesitant to be honest. The front page redirects to a GitHub repository that has had no activity in over 18 months, and a package where all the badges are broken. We generally only integrate with upstream services that are actively maintained and supported, which does not seem to be the case here. I'm curious to hear what @jNullj has to say as he was the one who originally deprecated this service.

[jNullj]

review: In #10618 I removed the service as it had no one to host it the service and was considered sun-setting. That was in october 2024. It seems that a user started hosting on his own around the beginning of 2025 and got the original domain. Considering the service is up for around a year I think we can restore it, worst case we start getting failing live tests we can take it down. I think we will not lose focus on other project goals over this as it doesn't change often and required code already exist and is field tested, as this should be a revert to what we used to have.

[sorki]

@sorki Could you fix the test for the issue mentioned at #10618 (comment) ? We assume the package is not out of date if we don't get a valid outdated message, this is not very robust. We might look for Database last updated at license endpoint or some other solution.

Looks like the current approach works correctly

• for non existent package we get 404 response (i.e. curl -v https://packdeps.haskellers.com/licenses/noSuchPackage)
• for existing package we get the expected message, i.e.:

$ curl -s https://packdeps.haskellers.com/feed/hnix | grep -o "Outdated dependencies for hnix"
Outdated dependencies for hnix

I've updated the comment and variable referencing /reverse to reflect reality in d780311

[jNullj]

When the site was down it served a landing page, this caused every request to return 200.

With current code we assume package exists and also up to date if we get a landing page, as the text out of date is missing.

This is not desireable as we suspect the service might stop working again and current test will pass our daily tests even if the service is down.

So I suggest using something a bit more robust to validate the page we get is actually still the site we expect.

Ofc you can offer another way to do that, my concern is only that we don't return false positive here.

If you need help I can help guide you.

[jNullj]

As for the example you provide, if the site is down and serves a landing page again it would look more like

curl -s https://google. com/ | grep -o "Outdated dependencies for hnix"
Outdated dependencies for hnix