MAAS cli doesn't know about maas command
Bug #1553605 reported by
Mark Shuttleworth
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
Medium
|
Unassigned |
Bug Description
The MAAS cli appears to have a very weird idea of the identity of the MAAS command itself:
mark@maas:~$ maas garage rack-controller
usage: /usr/lib/
The whole /usr/lib/
Usage: maas COMMAND [-h | --help]
For a list of commands, try "maas --help".
Related branches
lp:~mpontillo/maas/fix-1553605
- Andres Rodriguez (community): Approve
-
Diff: 23 lines (+13/-6)1 file modifieddebian/extras/maas (+13/-6)
Changed in maas: | |
importance: | Undecided → Medium |
status: | New → Triaged |
milestone: | none → 2.0.0 |
Changed in maas: | |
status: | Triaged → Fix Committed |
Changed in maas: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
This has been a pet peeve of mine for a long time, so thanks for the excuse to look into it. ;-)
Upon initial triage of this issue, I immediately noticed that it never occurrs in my development environment. But the problem always occurs with an installed version of MAAS. Comparing how the CLI is executed on an installed MAAS versus a development MAAS, it turns out that the problems stems from packaging. In the MAAS package, we were using a shell script to call the CLI code:
exec python -m maascli "$@"
When Python is called like this, it takes the module specified in the -m parameter, and replaces sys.argv[0] with the full path to that file.
If instead the wrapper is a Python script, Python will leave it as-is. So the fix is to replace our shell script wrapper with a Python-based wrapper.