facebook/hhvm

Getting started guide is using abandoned packages

justdan6 opened this issue · 3 comments

justdan6 commented

Describe the bug

I followed the guide at https://docs.hhvm.com/hack/getting-started/starting-a-real-project and found that the following packages are abandoned - hhvm/hhvm-autoload, facebook/difflib, facebook/fbexpect, hhvm/type-assert.

Standalone code, or other way to reproduce the problem

Visit https://docs.hhvm.com/hack/getting-started/starting-a-real-project and follow the guide.

Expected behavior

A guide that doesn't use abandoned packages.

Actual behavior

Package hhvm/hhvm-autoload is abandoned, you should avoid using it. No replacement was suggested.
Package facebook/difflib is abandoned, you should avoid using it. No replacement was suggested.
Package facebook/fbexpect is abandoned, you should avoid using it. No replacement was suggested.
Package hhvm/type-assert is abandoned, you should avoid using it. No replacement was suggested.

Environment

  • Operating system
    Ubuntu 20.04 in Docker
  • Installation method
    apt-get with dl.hhvm.com repository
  • HHVM Version
$ hhvm --version
HipHop VM 4.172.1 (rel) (non-lowptr)
Compiler: 1674160842_830863609
Repo schema: cf1b330880a6f9fdad1a6212563bd3d2544e68a0

$ hh_client --version
hackc-ae3b9a25eaad0eb57e21b53488ef326414baccef-4.172.1
lexidor commented

👋, this answer is a summary what I have been able to gather from public sources, filled in with some guesswork.

The projects got their "This package is abandoned" state on Packagist because the repositories got archived on GitHub. This archival process was done by a bot with high certainty. They happen as if by clockwork on the 1st of the month on projects which have not seen a commit to the main branch (master at the time of writing) for 13 months.

The projects are still compatible with hhvm 4.168 and 4.172 (released late last year). Some packages are also compatible with hhvm 6.33 (the latest nightly on Dockerhub and dl.hhvm.com). Many of them are likely incompatible with hhvm@master, but I can not confirm, since I don't have a build more recent than 6.33.

The "you should avoid using it" is Composer / Packagist language. Not a statement made by the Hack OSS Team or HHVM OSS Team. Composer / Packagist interpreted this signal (archiving the project) as a sign of abandonment. Packages / libraries that are abandoned by Meta1 go to FacebookArchive. An archival on GitHub does not signal much, other than to freeze contributions.

My own personal reading:
<speculation>
The projects are still just as safe to use as they were a couple of months ago. We can continue to use them on hhvm 4.173 and below for the time being. If anyone finds a security issue, they ought still report it to the White Hat program. For now, these libraries are well-written and battle tested. Forking and switching over to a community maintained variant of these core libs seems a little much right now. Let's wait for a statement from Meta. Let's hope they can say what the future holds for these packages and the rest of the Hack packages they maintain.
</speculation>

I do not speak for Meta in any capacity, but I will add replies to this issue when we know more. Anyone interested can subscribe to this GH issue. I'll keep close tabs on the blog and the affected repositories.

Footnotes

  1. Meta could be either Meta or Facebook. If reading Meta, you can think "Facebook" if it helps. Their OSS branding isn't fully Meta yet, for example FacebookArchive. ↩

justdan6 commented

Thanks a lot for all of that context!

  • ❤️1
lexidor commented

Hi all 👋, I am X-Posting this blog post from the hhvm blog. It is definitely worth a read. https://hhvm.com/blog/2023/10/27/oss-update.html

I can add a little extra context that is applicable to this issue (abandoned packages). The team that works on the Hack type checker and the team that accepts PRs on hhvm/_ and facebook/_ used to share some members. The workload on the Hack type checker team has increased, as can be read in this post. The team already has their hands full. For this reason, reviewing and merging Hack OSS lib PRs has been removed from the list of priorities.

What this means for hhvm/_ and facebook/_.
Meta won't be releasing new pre-built binaries of hhvm and the Hack typechecker. This means that anyone who is unable or unwilling to get a build of hhvm@master going will be stuck on hhvm 4.168/4.172. The packages still support those versions of hhvm and they are still fine to use. These packages should be considered as frozen, but not as abandoned.

Issues which affect the IT security of projects that use these libraries can should still be reported. It is unlikely that the Hack team will write a patch themselves, but they'll consider merging patches that fix these issues. New feature PRs should not be made, since they will not be merged.

I am torn on what would be the next step for the Hack OSS libs ecosystem. If we want new features, support for newer versions of hhvm, or non-security bug fixes, forking seems like the only path forward. I previously said that forking would be premature, but the latest blog post implies that maintaining open source Hack libraries is not something the Hack team can shoulder right now and for the foreseeable future. I will think deeply about this in the coming days/weeks.

  • 😕1