feat: requirements.txt support for maven plugin

[ih0r-d]

Description

Added support for reading Python dependencies from requirements.txt instead of standard tags in Maven configuration.

Fixes # (issue)

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Verified build with requirements.txt present
• Verified backward compatibility when requirements.txt is absent

Test Configuration:

• Firmware version: -
• Hardware: -
• Toolchain: Maven 3.9+, JDK 17
• SDK:

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: ih0r-d
• [email protected] (@ih0r-d)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[steve-s]

Hello, thank you for the contribution!

It seems that the code is somehow reformatted, which breaks the diff and makes it difficult to review. Can you please fix that?

Added support for reading Python dependencies from requirements.txt instead of standard tags in Maven configuration.

Can you explain how it's going to interact with the Maven based configuration? I assume it is going to be one or the other? Can you add some documentation into the PR description that we could then put to https://www.graalvm.org/python/docs/#embedding-build-tools, or even better make a companion PR to update the docs: https://github.com/oracle/graalpython/blob/master/docs/user/Embedding-Build-Tools.md?

We need some tests. See other tests in integration-tests directory. Those can be run from Maven, see https://github.com/oracle/graalpy-extensions/blob/main/DEVELOPMENT.md#integration-tests

We also require contributors to sign contributor agreement. It is a common practice, see the comment from the bot that checks this for more details.

[ih0r-d]

Thank you very much for the review and for pointing this out!

You’re right, the code was accidentally reformatted — I’ll revert the unrelated formatting changes and update the PR.

For the configuration, the idea is to have a single source of Python dependencies: either the block in the Maven configuration or a requirements.txt file. If both are present, the build will fail with a clear error.

I went with requirements.txt to align with common Python tooling conventions and make it easier to reuse existing dependency files.

I’ll update the PR description, add a brief note to the documentation you referenced, and incorporate integration tests to cover this behavior.

[steve-s]

It looks like you may have accidentally removed some existing code from the integration tests. Also, please use only English in the code, including comments. Otherwise, looks like it's on a good trajectory!

[steve-s]

Also please note that signing the Oracle contributor agreement is necessary requirement before we can merge this PR.

[ih0r-d]

Thanks for pointing this out!
You’re right, I accidentally removed some existing integration test code. I’ve restored it and updated all comments in the code to English.
In addition, I’ve opened a small companion PR with the documentation updates for this change. Please take a look when you have a moment.
oracle/graalpython#568

[steve-s]

Thank you, this looks good.

I see that requirements.txt is basically another way of encoding the same information as using <package> tags in pom.xml.

We planned similar feature, but wanted to make it such that if you specify requirements.txt file, we will just simply forward that file as-is to pip, i.e., run pip install -r the/specified/requirements/file.txt, so that a Python power user can use any feature of pip's requirements.txt format (with the caveat that this way the built-in package locking will not be available, but the assumption is that a power user will want to handle the locking themselves). What do you think about that approach?

[ih0r-d]

Thanks for the feedback!

In my current implementation, I parse the requirements file and convert it into a list of packages, which is then passed to the existing installation logic. Now I see that the intended behavior is different — simply forwarding the file directly to pip install -r <file> without parsing.

I can update the PR to match this approach.
Please let me know if you'd like me to adjust the implementation accordingly — I’m happy to make the updates.

[ih0r-d]

I've updated the logic to support requirements.txt and align with pip’s native behavior.
The plugin now forwards the specified requirements file directly to pip (pip install -r <file>). In this mode:

• No GraalPy lock file is used or generated
• The lock-packages goal is disabled
• Dependency resolution fully relies on pip, giving users complete flexibility

The implementation clearly separates two independent flows:

• requirementsFile → pip-native installation
• <packages> → existing GraalPy locking flow

This prevents configuration mixing and keeps the behavior explicit.
Please let me know if you'd like any adjustments!