mirror of
https://github.com/apple/pkl.git
synced 2026-09-03 08:27:25 +02:00
Support for -SNAPSHOT versions that do not cache the package locally
#99
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/pkl#99
Reference in New Issue
Block a user
Originally created by @StefMa on GitHub (Mar 1, 2024).
I don't know exactly how caching works on
pkl.But I assume it is just basic support yet.
Once a package was requested, it will be stored in the cache directory.
If requested again it will be used from the cache directory instead from the package server.
Coming from the JVM-World I think it would be quite nice to support
-SNAPSHOTversions in the same way Gradle and Maven (I guess) supports it.Being said, if requested a -SNAPSHOT version it will "always" check the package server to find out if there is a new version of that SNAPSHOT version.
How this works behind the scenes (in the Gradle world)?
Each time you create/publish a SNAPSHOT version the tool will add a timestamp to the package (to distinguish between multiple SNAPSHOT versions).
If requested, the "latest" (timestamp) SNAPSHOT version will be downloaded.
However, how pkl support could look differently 🙃
@odenix commented on GitHub (Mar 3, 2024):
Which aspect of snapshot versions are you interested in? Easy update to the latest version for package consumers, or something else?
@StefMa commented on GitHub (Mar 3, 2024):
I guess it's a feature for both, consumers and package servers. While the first one might be more important.
The feature should work that a consumer might get an updated/new/another version of a package without updating the package version.
He defines like
package://package.server/something@version-SNAPAHOT#/Something.pklandpklwill each time request that package from the package server instead of using the cache.However, this feature might also be supported by the package server to override package versions. While this works currently with github releases (because you can delete the release and create a new/the same one) that workflow is a bit awkward and annoying.
Does this make sense? 🤔
@odenix commented on GitHub (Mar 3, 2024):
Personally I'm more interested in the consumer side. For the producer, it seems OK to publish a normal release every time.
@StefMa commented on GitHub (Mar 3, 2024):
Maybe a simple CLI option
--no-cacheor something would be sufficient 🤔@odenix commented on GitHub (Mar 3, 2024):
What I have in mind is a package URL such as
package://example.com/mypackage@latest. When used for a dependency declared inPklProject, such an URL would be resolved to a concrete version bypkl project resolve. Perhaps the latest version could be found by following an HTTP redirect.@bioball commented on GitHub (Mar 4, 2024):
We are considering supporting something like "latest". The tricky bit is that right now, our
package:protocol does not have the concept of an index, nor a registry.@bvalyou commented on GitHub (Mar 7, 2024):
The other thing in this area that I'm looking at is how to manage dependency versions programmatically, similar to
npm install package@version. I'm curious if there are plans to support something likepkl project dependencies -n <name> -v <version>.