[RFC] qcom_ptool: add packaging and a single qcom-ptool CLI entry point#108
Open
igoropaniuk wants to merge 6 commits intoqualcomm-linux:mainfrom
Open
[RFC] qcom_ptool: add packaging and a single qcom-ptool CLI entry point#108igoropaniuk wants to merge 6 commits intoqualcomm-linux:mainfrom
igoropaniuk wants to merge 6 commits intoqualcomm-linux:mainfrom
Conversation
The five scripts currently live at the repo root as standalone executables, which makes it impossible to ship the tool as a regular Python distribution or to present a single unified entry point to users. Relocate them under qcom_ptool/ so the following commits can turn the tree into a pip-installable package exposing one qcom-ptool CLI. Pure rename; git tracks the move at 100% similarity so history and review stay clean. Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
After the move, ptool.py and msp.py still do `from utils import ...`. That worked when both files lived side by side at the repo root and sys.path happened to contain the cwd, but it breaks as soon as the tool is invoked from anywhere else or run via `python -m`, because `utils` is no longer a top-level module. The whole point of putting the code in a package is to stop relying on that fragile sys.path behaviour, so use the absolute qcom_ptool.utils path instead. Add an empty __init__.py (carrying the version string) so the directory is recognised as a regular package and becomes importable as `qcom_ptool` -- a prerequisite for the build backend and the CLI dispatcher added in the next commit. Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
The project has no [build-system] section today, so it cannot be built as a wheel or installed with pip; consumers are expected to either put each of the five scripts on PATH by hand or invoke them by absolute path from the repo root. That's awkward for downstreams (meta-qcom, qcom-deb-images) and offers no clear version or entry point. Declare a setuptools build backend and a [project.scripts] entry that exposes a single `qcom-ptool` command with gen_partition, gen_contents, ptool and msp as subcommands. Downstreams can then `pip install .` and get one consistent, versioned interface regardless of how the tool is deployed. Keep the legacy top-level argument parsing inside ptool.py and msp.py intact: the dispatcher rewrites sys.argv and calls runpy.run_module() with run_name="__main__" so each module runs as if it had been invoked directly. Refactoring thousands of lines of top-level, globals-heavy legacy code into main() functions would be a disproportionate risk for what is fundamentally a packaging change, so defer it. Also update the isort first-party list and the mypy overrides to match the new qcom_ptool.* module names. Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
With the sources moved into qcom_ptool/, the scripts no longer exist at the repo-root paths the Makefile was calling, and the intended supported invocation is now the installed `qcom-ptool` command. Update the rules to call `qcom-ptool <subcommand>` so that generating partition XMLs, contents and GPT binaries goes through the same entry point end users will use, and point `make lint` at the package directory instead of repo-root *.py (there are no *.py at the root anymore). Have `make install` delegate to `pip install .` so there is one installation path, and add `pip install -e .` to the CI workflow so the qcom-ptool command is available on PATH before `make all` integration runs. Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
Users landing on the repo would otherwise still expect five standalone scripts at the repo root and have no pointer to the new installation flow or the `qcom-ptool` command. Add an Installation section showing `pip install .` and the `qcom-ptool <subcommand>` invocation for each utility, and call out that the Makefile now relies on the CLI being on PATH so downstream users don't try to run `make` before installing the package. Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
Now that the repo is a proper Python distribution, running `pip install` (editable or not) and building a wheel drop build/, dist/ and *.egg-info/ directories into the source tree. These are strictly build outputs and show up as noise in `git status` for anyone working on the tool, so keep them untracked. Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
Contributor
Author
|
FYI @lool @lumag @ndechesne @vkraleti could you take a look? thanks |
lool
reviewed
Apr 24, 2026
Contributor
lool
left a comment
There was a problem hiding this comment.
I'm not a maintainer, but the changes looked good to me. The one thing that made me pause was the new CLI interface (qcom-ptool): should we take this opportunity to define clear verbs for what people might do with the new frontend and how they chain to one-another? Perhaps that's a long detour though
lumag
approved these changes
Apr 25, 2026
Contributor
lumag
left a comment
There was a problem hiding this comment.
I'm approving this change, but I'd also like to give other engineers time to look at it.
@igoropaniuk If nothing happens before Wednesday, could you please ping me, I'll merge the changes.
(Thanks a lot for taking care of these matters).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This series packages
qcom-ptoolas a regular pip-installable Python distribution so downstreams (meta-qcom, qcom-deb-images, etc.) can consume it through a single versioned interface instead of copying five loose scripts onto PATH.The five utilities are moved under a new
qcom_ptool/package and exposed behind one qcom-ptool command withgen_partition,gen_contents,ptoolandmspsubcommands, wired up via[build-system]and[project.scripts]in pyproject.toml.The CLI dispatcher delegates through runpy so the legacy top-level argument parsing in
ptool.pyandmsp.pykeeps working unchanged - the refactor needed to turn those scripts into proper main() functions would be disproportionate for what is fundamentally a packaging change.Makefile, CI and README are updated to install the package and invoke the new CLI;
make lint(ruff + mypy) andmake allintegration pass end-to-end.