Reliable way to validate requirements.txt for aarch64 without checking each package manually? And precompiled modules for easy deployment?

Python, Perl and Golang Python
1

Hi everyone,

I’m working on a Python project that targets aarch64 architecture (like on AWS Graviton), and I’m looking for a reliable way to verify the content of my requirements.txt file to:

  1. Ensure I have the latest compatible version of each library.

  2. Avoid version conflicts between dependencies.

  3. Prevent having to manually check each package’s documentation one by one.

Is there a tool or workflow that can handle this efficiently, specifically for aarch64 systems? Ideally, I’d like something that can tell me what versions are safe to use together without breaking compatibility.

Follow-up question:

In some cases, certain packages (like prophet, scikit-learn, or anything involving native code) require compilation from source on aarch64, which can be a nightmare for non-technical users.

Is there a legal and practical way to:

Precompile these libraries for aarch64 and Host them somewhere (e.g., internal PyPI server, cloud storage, etc.) so that non-technical users don’t have to build from source themselves?

Would this approach be compatible with open source licenses? And is there any standard way to bundle or distribute those precompiled wheels for private or internal use?

Thanks a lot!

2

I am currently using https://github.com/jazzband/pip-tools. To avoid those 3 points you mentioned above.

However they are out here most sophisticated ones but pip-tools have been good to me.

The other ones (among others):

Poetry

PDM

There cons and props for each one but definitely do not develop without one.

Non-technical users don’t have to build from source themselves

Non technical users are going to be deploying your app in the cloud?.

On thing you can do is dockerize your app and write some bash script for the non-technical user.

1 Like
3

When working with aarch64 architecture, ensuring that your dependencies are compatible without manually verifying each package can be a bit challenging. Fortunately, there are efficient ways to automate the process and streamline deployment.

You can validate your requirements.txt for aarch64 by running pip install -r requirements.txt --no-binary :all:. This forces pip to install the packages from source, ensuring they are compatible with the aarch64 architecture. For precompiled modules, consider looking for prebuilt versions or use a CDN/repository that provides aarch64-compatible packages, making deployment smoother.

4

Thanks! You’re absolutely right that pip-tools, Poetry or PDM are great for managing complex dependencies.

In my case, I’ve implemented a fully automated cloud deployment system using GitHub Actions and workflows that handle everything:

  • Dependencies are pinned and managed automatically.
  • Architecture-specific builds (like aarch64) are pre-handled.
  • No need for users to build from source or understand Docker.
  • Non-technical users can deploy the entire stack with one click through a public repo and a CI/CD workflow.

Since everything is handled behind the scenes, even those with zero programming experience can run the system in the cloud without any technical setup.

Appreciate your insight — it’s a great topic to revisit.

5

That’s a really helpful angle — thanks!

My original question came from the need to validate the requirements.txt itself for aarch64 — not just during install, but even before freezing dependencies — ideally without manually inspecting each package.

To get there, I ran controlled tests on a real-world aarch64 environment using an automated install-check script. This helped identify packages that failed to build or had architecture issues. I then replaced or adjusted them manually, and the result is a stable, working list that deploys cleanly through GitHub Actions with architecture-aware workflows.

That said, I’m still looking for a more standardized or programmatic way to verify future changes or new packages, ideally earlier in the chain.

Your suggestion about using --no-binary :all: is spot on — I do use it during CI for internal checks, even if it’s not suitable for non-technical users. Much appreciated!