Allow custom charm parts with the go_framework extension
Metadata
Current evaluation
Feature request: go_framework extension rejects any custom parts in charmcraft.yaml, blocking shared-module monorepos and conflicting with the new monorepo packing docs. Escalated to the design wheelhouse for a decision.
Suggested action: keep open
Reason: The limitation is real and verified against the reporter's quoted error ('the go-framework extension is incompatible with customized charm part'), and lengau explicitly acknowledged it as a valid use case while saying 'this is your design wheelhouse... it's up to you whether we want to support it' — triaged and valid, not stale. It remains a deliberate design decision rather than a defect: the extension intentionally assumes it owns the charm part, and relaxing it requires defining how custom parts interact with the extension's part-installation logic (notably the tension the reporter raises with the monorepo docs). No implementation scope or acceptance criteria exist yet, and the decision is pending with @alithethird/@javierdelapuente, so actionability is mid-range. Impact is moderate rather than high: it affects Go charm authors using the extension who also need monorepo layouts, and they have documented workarounds (drop the extension, or duplicate code), but it is not an app-breaking bug. Confidence is limited because repository tooling returned 'No pinned SHA available for project charmcraft', so I could not inspect charmcraft/extensions/ or the extension tests to confirm the current guard, its blast radius, or whether any related PR is already in flight.
Evaluated by: mr-cal-bot
Issue body
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
45
Quick Win:
8
Complexity:
65
Confidence:
68
Actionability:
50
|
keep open | Feature request: go_framework extension rejects any custom parts in charmcraft.yaml, blocking shared-module monorepos and conflicting with the new monorepo packing docs. Escalated to the design wheelhouse for a decision. | |
| stealth/space-bunny-alpha |
Impact:
55
Quick Win:
12
Complexity:
58
Confidence:
91
Actionability:
52
|
keep open | go_framework rejects custom parts, blocking shared-module monorepos and conflicting with planned monorepo packaging docs; the design wheelhouse has been asked to decide whether to support it. | |
| qwen/qwen3.6-35b-a3b |
Impact:
65
Quick Win:
29
Staleness:
5
Complexity:
55
Confidence:
75
Support Request:
25
|
needs triage | Feature request to allow go_framework extension with custom charm parts. Currently blocked by intentional design check in charmcraft/extensions/app.py. Awaiting design team review per @lengau's comment. | |
| qwen/qwen3.6-35b-a3b |
Impact:
65
Quick Win:
23
Staleness:
0
Complexity:
65
Confidence:
75
Support Request:
20
|
needs triage | Feature request to allow go_framework extension with customized charm parts for monorepo support. Currently blocked by explicit validation in charmcraft/extensions/app.py. Unlabelled, no maintainer response. |
Update history
| Date | Change |
|---|---|
| updated | |
| created |
Related work
-
Related To:
charmcraft#2844
(confidence 80%)
Merged PR #2844 added the Charmcraft 4.5 'pack a charm in a monorepos' how-to that the issue cites as conflicting with the extension's restriction; its documented custom `parts` example is unusable with go_framework.
Related issues
No related issues found above the similarity threshold.