Pkl package using private repo (using authentication) #201

Open
opened 2025-12-30 01:22:04 +01:00 by adam · 2 comments
Owner

Originally created by @KyleReczek-AbsorbLMS on GitHub (Aug 22, 2024).

We were trying to host our pkl releases in a private gitlab repo. However according to this discussion

https://github.com/apple/pkl/discussions/632 that's not possible.

Could I suggest adding a method to allow for using authentication with packages?

Originally created by @KyleReczek-AbsorbLMS on GitHub (Aug 22, 2024). We were trying to host our pkl releases in a private gitlab repo. However according to this discussion https://github.com/apple/pkl/discussions/632 that's not possible. Could I suggest adding a method to allow for using authentication with packages?
Author
Owner

@bioball commented on GitHub (Sep 6, 2024):

This definitely makes sense to have, and is something that we plan on supporting in a future release.

@bioball commented on GitHub (Sep 6, 2024): This definitely makes sense to have, and is something that we plan on supporting in a future release.
Author
Owner

@sin-ack commented on GitHub (Feb 27, 2025):

Could this be implemented through external module readers in the meantime? It would require all dependencies to depend on the custom scheme exposed by the external module reader instead of the @package notation, but it could allow customized authentication. In fact, I'd actually want to see package: either go away and be replaced with arbitrary schemas (which could allow using external module readers for loading dependencies) or allow defining an external module reader for package: to define how exactly a package should be resolved. This way Pkl opens the door to customizing dependency resolution as well.

@sin-ack commented on GitHub (Feb 27, 2025): Could this be implemented through external module readers in the meantime? It would require all dependencies to depend on the custom scheme exposed by the external module reader instead of the `@package` notation, but it could allow customized authentication. In fact, I'd actually want to see `package:` either go away and be replaced with arbitrary schemas (which could allow using external module readers for loading dependencies) or allow defining an external module reader for `package:` to define how exactly a package should be resolved. This way Pkl opens the door to customizing dependency resolution as well.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#201