charmcraft upload should take a path directly
Metadata
Current evaluation
Positional upload paths were implemented; automatic charm-file discovery was split into #312 and rejected because bases builds may produce multiple complex artifacts.
Resolution: closed resolved
Reason: A maintainer confirmed that charmcraft upload <filepath> was available and moved only the automatic-discovery proposal to #312. That follow-up was closed because bases builds can create multiple, complexly named artifacts.
Evaluated by: mr-cal-bot
No scores available.
Issue body
It would be nicer to say:
```
$ charmcraft upload filename.charm
```
than the current
```
charmcraft upload --charm-file=filename.charm
```
In the same spirit, if we can actually use a metadata.yaml, then providing a path to the metadata.yaml, or a path to a directory with a metadata.yaml, would work. If there are multiple architecture builds in that directory in future then we could either try to upload them all or abort with a list and tell the user to be more specific.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha | — | closed resolved | Positional upload paths were implemented; automatic charm-file discovery was split into #312 and rejected because bases builds may produce multiple complex artifacts. | |
| stealth/space-bunny-alpha | — | closed resolved | Charmcraft upload now accepts a required positional artifact path. Automatic artifact discovery was moved to #312 and rejected because bases builds may produce multiple artifacts. | |
| stealth/space-bunny-alpha | — | closed not a bug | Automatic upload-file discovery was rejected in #312, which kept explicit filepath selection because bases builds can produce multiple, complexly named artifacts. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Superseded by issue #312. The direct path argument was removed from the CLI, and automatic filepath detection was tracked separately. | |
| qwen/qwen3.6-35b-a3b | — | — | Superseded by issue #312. The explicit filepath option was removed from the CLI, and automatic path detection was tracked separately. The request was closed without implementation. | |
| qwen/qwen3.6-35b-a3b | — | — | The proposal to simplify charmcraft upload by accepting a direct path was closed. The direct path option was removed, and automatic filepath detection was instead tracked in issue #312. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Superseded by issue #312. Direct path specification was removed, and automatic filepath detection was tracked separately. The request was closed as the team shifted to a new implementation approach. |
Update history
No update history recorded yet.
Related work
-
Related To:
charmcraft#312
(confidence 99%)
Follow-up issue for automatic path discovery; it was rejected because bases builds may produce multiple artifacts.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #312 Do not require the filepath in charmcraft upload | charmcraft | closed | Automatic upload-path discovery was rejected; charmcraft upload keeps requiring an explicit filepath because bases builds may create multiple, complexly named artifacts. | |
| #1263 `charmcraft upload` should be able to take several `*.charm` files at once | charmcraft | closed | Closed by the reporter as expected behaviour: maintainers explained Charmhub supports charms of different bases per revision, so per-base .charm files are uploaded separately and Juju picks the right one. No code change. |