facebook / pyre-check

Performant type-checking for python.
https://pyre-check.org/
MIT License
6.86k stars 437 forks source link

pyre.bin does not work on Debian Bullseye (glibc 2.31) #922

Open filbranden opened 1 month ago

filbranden commented 1 month ago

Pyre Bug

Bug description Latest pyre versions 0.9.21 and 0.9.22 from PyPI do not work on Debian Bullseye with glibc 2.31

Reproduction steps

$ sudo pip install pyre-check==0.9.21
$ pyre.bin
pyre.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by pyre.bin)
pyre.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by pyre.bin)
pyre.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by pyre.bin)

Expected behavior Expecting the binary to work, as it does on 0.9.19

$ sudo pip install pyre-check==0.9.19
$ pyre.bin
pyre: required COMMAND name is missing, must be one of 'analyze', 'check', 'code-navigation', 'infer', 'newanalyze', 'newcheck', 'newinfer', 'newserver', 'no-daemon-query' or 'server'.
Usage: pyre COMMAND …
Try 'pyre --help' for more information.

Logs

Output of pyre rage:

Versions
========
Client version: 0.9.21
Binary version: None

Configuration
=============
{
  "global_root": "/home/filipe",
  "dot_pyre_directory": "None",
  "only_check_paths": [],
  "excludes": [],
  "extensions": [],
  "ignore_all_errors": [],
  "other_critical_files": [],
  "search_path": [],
  "optional_search_path": [],
  "site_package_search_strategy": "none",
  "site_roots": [],
  "strict": false,
  "taint_models_path": [],
  "use_buck2": false
}

Watchman Watch-list
===================
{
    "version": "4.9.0",
    "roots": []
}

Additional context

Probably related to a build environment or ocaml compiler used during builds, regression seemed to be introduced between 0.9.19 and 0.9.21

samwgoldman commented 1 month ago

Thanks for the report! This is a really unfortunate issue, although a known one (#873). We build these binaries internally on machines where we don't control the build toolchain. We need to move these builds, but haven't prioritized that work yet. Honestly it kind of fell off my radar, so I'll take another look today.

filbranden commented 1 month ago

Thank you!

If I can make a suggestion, building in a container should be a good way to get reproducible builds without having the underlying host environment affect your system. Happy to provide you with a PR to build in a container in GitHub Actions if you'd like that (but it seems you moved away from GitHub Actions for a reason, so not sure if that's what you're looking for.)

Cheers!