[Feature] Support badges of latest version on your package server (pkg.pkl-lang.org) #113

Open
opened 2025-12-30 01:21:01 +01:00 by adam · 3 comments
Owner

Originally created by @StefMa on GitHub (Mar 13, 2024).

I want to add a badge to my README file that shows the latest version that consumers can use.
Similar to other badges supported by https://shields.io

I guess a Pkl server requires to send the latest version if requested with latestor something so shields.io (or others) can use that API to display the latest version.

Its a bit related/similar to https://github.com/apple/pkl/issues/278 or better to this comment.

If you support using e.g. package://pkg.pkl-lang.org/github.com/stefma/pkl-gha/com.github.action@latest and this would redirect to the latest version (0.0.1 🤷), then it would be possible to implement... I guess 😁

Also not sure if this issue should be better placed at https://github.com/apple/pkl-lang.org 🤷
Feel free to move it.

Originally created by @StefMa on GitHub (Mar 13, 2024). I want to add a badge to my README file that shows the latest version that consumers can use. Similar to other badges supported by https://shields.io I guess a Pkl server requires to send the latest version if requested with `latest`or something so shields.io (or others) can use that API to display the latest version. Its a bit related/similar to https://github.com/apple/pkl/issues/278 or better [to this comment](https://github.com/apple/pkl/issues/278#issuecomment-1977152027). If you support using e.g. `package://pkg.pkl-lang.org/github.com/stefma/pkl-gha/com.github.action@latest` and this would redirect to the latest version (0.0.1 🤷), then it would be possible to implement... I guess 😁 Also not sure if this issue should be better placed at https://github.com/apple/pkl-lang.org 🤷 Feel free to move it.
Author
Owner

@StefMa commented on GitHub (Mar 13, 2024):

For now, we can use the GitHub releases badge (https://shields.io/badges/git-hub-release) as the pkl package server supports only that.
GitHub Release

But that is obiosuly not perfect as maybe in the future the pkl package server supports multiple different sources for packages.

@StefMa commented on GitHub (Mar 13, 2024): For now, we can use the GitHub releases badge (https://shields.io/badges/git-hub-release) as the pkl package server supports only that. ![GitHub Release](https://img.shields.io/github/v/release/stefma/pkl-gha?include_prereleases) But that is obiosuly not perfect as maybe in the future the pkl package server supports multiple different sources for packages.
Author
Owner

@holzensp commented on GitHub (Mar 13, 2024):

I think this is a reasonable ask. I think this will mostly depend on how we support the latest concept in Pkl itself. We could roll something quickly for pkg.pkl-lang.org, but if we later find out subtle incompatibilities with latest in Pkl itself, it'll be regrettable.

That said, we can start having a discussion. Are you only interested in latest, or in <major>.latest as well? Why (not)?

@holzensp commented on GitHub (Mar 13, 2024): I think this is a reasonable ask. I think this will mostly depend on how we support the `latest` concept in Pkl itself. We _could_ roll something quickly for `pkg.pkl-lang.org`, but if we later find out subtle incompatibilities with `latest` in Pkl itself, it'll be regrettable. That said, we can start having a discussion. Are you only interested in `latest`, or in `<major>.latest` as well? Why (not)?
Author
Owner

@StefMa commented on GitHub (Mar 13, 2024):

Are you only interested in latest, or in .latest as well? Why (not)?

In terms of this feature just latest would be required.
Mostly, these badges are used to displaying the "really latest" version.
Independent from the major version.

I'm not sure if <major>.latest make sense to have. 🤔
The only use case would I found would be to avoid breaking changes.
Like "I want to have the latest version of version 1, regardless of the minor and patch, but don't want to upgrade to version 2 yet".
But for this case, I would rather support this "internally" on a pkl server than make it public.
What I mean is that it could be possible to request a package like package://[yadayada]/packageName#1 (1 instead of a semver version).
The package server will then resolve this internally to the "latest semver version of version 1".

So.. No, I think we don't need <major>.latest ... 🤔

@StefMa commented on GitHub (Mar 13, 2024): > Are you only interested in latest, or in <major>.latest as well? Why (not)? In terms of *this feature* just `latest` would be **required**. Mostly, these badges are used to displaying the "really latest" version. Independent from the `major` version. I'm not sure if `<major>.latest` make sense to have. 🤔 The only use case would I found would be to avoid breaking changes. Like "I want to have the latest version of version 1, regardless of the minor and patch, but don't want to upgrade to version 2 yet". But for this case, I would rather support this "internally" on a pkl server than make it public. What I mean is that it could be possible to request a package like `package://[yadayada]/packageName#1` (1 instead of a semver version). The package server will then resolve this internally to the "latest semver version of version 1". So.. No, I think we don't need `<major>.latest` ... 🤔
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#113