ZEP-0013: Improve Package Publish UX #14
Conversation
AustinAbro321
commented
Jan 24, 2025
AustinAbro321
commented
- One-line PR description: Introduce initial draft of ZEP
- Issue link: Improve Package Publish UX #13
Signed-off-by: Austin Abro <AustinAbro321@gmail.com>
Signed-off-by: Austin Abro <AustinAbro321@gmail.com>
AustinAbro321
changed the title
| [documentation style guide]: https://docs.zarf.dev/contribute/style-guide/ | ||
| --> | ||
|
|
||
| `zarf package publish` accepts either a directory with a `zarf.yaml` file or a created Zarf package. The behavior when accepting a directory is to create and publish a [skeleton package](https://docs.zarf.dev/faq/#what-is-a-skeleton-zarf-package). This is not intuitive, the average user would most likely expect a package to be built then published. They likely wouldn't know what a skeleton package is as well. Instead we will make an explicit command `zarf package publish skeleton` for skeleton package users. |
There was a problem hiding this comment.
If you're claiming that users don't know what a skeleton package is, why not better explain what it is and how that works, rather than introducing entirely separate command, with the skeleton name in it? IMO, the improved UX in that case is questionable. Maybe rather than calling this a skeleton package, we can just say a directory containing zarf.yaml?
There was a problem hiding this comment.
Ideally, link to https://docs.zarf.dev/faq/#what-is-a-skeleton-zarf-package
There was a problem hiding this comment.
I agree we should add this link, or at least another hook for users to better understand skeleton packages. And I think this is something we can do now whether or not this ZEP is merged. Still, I am generally not a fan of the overloaded nature this puts the publish command into. The result of the publish is entirely different when it receives a directory vs when it receives a package.
There was a problem hiding this comment.
Another reason behind my motivation here is that I don't believe skeleton packages are a particularly well thought out feature. They do solve a problem of making custom init packages easier to maintain, but besides that I'm not sure I've heard of anyone using them. I've also found bugs in skeleton packages that have been around for a while and were never reported. Will add this to the motivation section.
| [kubernetes slack]: https://kubernetes.slack.com/archives/C03B6BJAUJ3 | ||
| --> | ||
|
|
||
| We have seen multiple questions in Kubernetes slack asking why their package was published without images. The user assumed it was a bug, instead it was the skeleton package feature. |
There was a problem hiding this comment.
Again, if this is how this works, maybe we just need to ensure the user is aware. This can be achieve through explicitly telling them that "you're publishing a skeleton package, the images will not be pushed". Or something similar, clearly expressing this limitation.
|
Closing this in favor of zarf-dev/zarf#3482, which makes it more clear to the user they are posting a skeleton package and links to the docs |
