apple
Support for `-SNAPSHOT` versions that do not cache the package locally
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 -SNAPSHOT versions 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 🙃
Which aspect of snapshot versions are you interested in? Easy update to the latest version for package consumers, or something else?
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.pkl and pkl will 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? 🤔
Personally I'm more interested in the consumer side. For the producer, it seems OK to publish a normal release every time.
What I have in mind is a package URL such as package://example.com/mypackage@latest. When used for a dependency declared in PklProject, such an URL would be resolved to a concrete version by pkl project resolve. Perhaps the latest version could be found by following an HTTP redirect.
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.
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 like pkl project dependencies -n <name> -v <version>.
