Skip to content

[RFC] qcom_ptool: add packaging and a single qcom-ptool CLI entry point#108

Open
igoropaniuk wants to merge 6 commits intoqualcomm-linux:mainfrom
igoropaniuk:feat/qcom-ptool-package
Open

[RFC] qcom_ptool: add packaging and a single qcom-ptool CLI entry point#108
igoropaniuk wants to merge 6 commits intoqualcomm-linux:mainfrom
igoropaniuk:feat/qcom-ptool-package

Conversation

@igoropaniuk
Copy link
Copy Markdown
Contributor

This series packages qcom-ptool as 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 with gen_partition, gen_contents, ptool and msp subcommands, 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.py and msp.py keeps 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) and make all integration pass end-to-end.

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>
@igoropaniuk
Copy link
Copy Markdown
Contributor Author

FYI @lool

@lumag @ndechesne @vkraleti could you take a look? thanks

@igoropaniuk igoropaniuk changed the title qcom_ptool: add packaging and a single qcom-ptool CLI entry point [RFC] qcom_ptool: add packaging and a single qcom-ptool CLI entry point Apr 24, 2026
Copy link
Copy Markdown
Contributor

@lool lool left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

@lumag lumag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants