[Suggestion] Refactor mx.py, source file too large
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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