graalvm / graalvm/mx

[Suggestion] Refactor mx.py, source file too large

Open
#194 16 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
205
Forks
129
PR merge metrics
No merged PRs in 30d

Description

mx.py is growing rapidly and with this can be unreadable over time.

IDEs like IntelliJ/PyCharm are slowing down parsing the contents. Besides that its best to separate the different aspects of mx.py into separate source files/modules of their own, just like the other mx_[xxx].py files out there.

I glanced through the code and here are some of the high-level parts we could split mx.py into:

  • high-level tasks i.e. build, test, benchmark, etc...
  • git related functionality
  • hg related functionality
  • code blocks that split tasks into processes for multi-processing
  • suite related functionality (Creation and other management tasks)
  • dependency resolution related functionality
  • maven & dependency resolution related functionality
  • gradle & dependency resolution related functionality
  • distribution related functionality
  • IDE related functionality
  • others...

Please make your own suggestions on how you would best like it to be split, but from the current layout of the classes and methods in it, the above was apparent but maybe a better design is inherent and I'm not seeing it immediately.

A good rule to keep such important files lean: only have high-level implementations that outline what the program does, and the how it does it (i.e. implementation parts) would be best to encapsulate elsewhere via Packages, Modules, Classes, etc... This would make it easier to read and change, especially to debug when things break.

I'm happy to slowly refactor it and create PRs for individual concerns - let me know if this is okay and I will create a simple PR to start with?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading mx.py and comparing its structure with the existing mx_[xxx].py modules. Use the listed concerns—build and test tasks, version-control functionality, dependency resolution, distributions, and IDE support—to propose boundaries for separate modules. Done means a reviewed refactoring plan or incremental changes that make mx.py smaller without changing its behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.