starred/pkl
1
0
Fork 0
mirror of https://github.com/apple/pkl.git synced 2026-01-13 15:13:38 +01:00
Code Issues 198 Packages Projects Releases 10 Wiki Activity

Mirrored packages support #144

New Issue
Closed
opened 2025-12-30 01:21:26 +01:00 by adam · 3 comments
adam commented 2025-12-30 01:21:26 +01:00
Owner
Copy Link

Originally created by @bvalyou on GitHub (Apr 11, 2024).

I have dependency mirroring and mirror replication as requirements for my intended use case. I have some ideas for how to hack around it short term but would like to understand how mirroring (referenced in https://github.com/apple/pkl/issues/153) is intended to work long term so I can limit rework later.

My guess is that there will be an argument to pkl project resolve like --mirror pkg.pkl-lang.org=example.com/pkl (supporting multiple mirrors) which would act as a replacer pattern for package manifests when pulling into the cache.

My current thought for working around it is to mirror the raw dependency (in an OCI repo, https://github.com/apple/pkl/issues/354) and for each dependency of my project

  • download the dependency explicitly and unpack the zip
  • run a string replace based on the mirror, e.g. pkg.pkl-lang.org -> example.com/pkl from above, in the manifest (and assume for right now that all dependencies are in the manifest rather than inlined in an import in source)
  • generate a PklProject file for the dependency based on the updated manifest and a defined folder structure
  • recurse through its dependencies

Then use all resolved dependencies as local dependencies.

I'll also have to mirror all transitive dependencies on the inbound side but that's workable.

It would be a big help to understand if this is wildly different from the planned mirror support or if I'm over-engineering it (which wouldn't shock me).

Thanks!

Originally created by @bvalyou on GitHub (Apr 11, 2024). I have dependency mirroring and mirror replication as requirements for my intended use case. I have some ideas for how to hack around it short term but would like to understand how mirroring (referenced in https://github.com/apple/pkl/issues/153) is intended to work long term so I can limit rework later. My guess is that there will be an argument to `pkl project resolve` like `--mirror pkg.pkl-lang.org=example.com/pkl` (supporting multiple mirrors) which would act as a replacer pattern for package manifests when pulling into the cache. My current thought for working around it is to mirror the raw dependency (in an OCI repo, https://github.com/apple/pkl/issues/354) and for each dependency of my project * download the dependency explicitly and unpack the zip * run a string replace based on the mirror, e.g. pkg.pkl-lang.org -> example.com/pkl from above, in the manifest (and assume for right now that all dependencies are in the manifest rather than inlined in an import in source) * generate a PklProject file for the dependency based on the updated manifest and a defined folder structure * recurse through its dependencies Then use all resolved dependencies as local dependencies. I'll also have to mirror all transitive dependencies on the inbound side but that's workable. It would be a big help to understand if this is wildly different from the planned mirror support or if I'm over-engineering it (which wouldn't shock me). Thanks!
adam closed this issue 2025-12-30 01:21:26 +01:00
adam commented 2025-12-30 01:21:27 +01:00
Author
Owner
Copy Link

@bioball commented on GitHub (Apr 13, 2024):

I know you already said mirroring is a requirement, but: would HTTP proxying be good enough for you?

To support mirroring, we are considering rewrite rules. This is hand-wavey, but, possibly would work by adding something to the Pkl settings file. Something like:

groovy

// ~/.pkl/settings.pkl

packageRewriteRules {
  [#"https://pkg.pkl-lang.org/.*/(\w+)#] = "https://my.company.com/$1/$1"
}

But, we wouldn't implement this if HTTP proxying is good enough.

@bioball commented on GitHub (Apr 13, 2024): I know you already said mirroring is a requirement, but: would HTTP proxying be good enough for you? To support mirroring, we are considering rewrite rules. This is hand-wavey, but, possibly would work by adding something to the Pkl settings file. Something like: groovy ``` // ~/.pkl/settings.pkl packageRewriteRules { [#"https://pkg.pkl-lang.org/.*/(\w+)#] = "https://my.company.com/$1/$1" } ``` But, we wouldn't implement this if HTTP proxying is good enough.
adam commented 2025-12-30 01:21:27 +01:00
Author
Owner
Copy Link

@bvalyou commented on GitHub (Apr 15, 2024):

HTTP proxy is not good enough, unfortunately

@bvalyou commented on GitHub (Apr 15, 2024): HTTP proxy is not good enough, unfortunately
adam commented 2025-12-30 01:21:28 +01:00
Author
Owner
Copy Link

@bioball commented on GitHub (Jul 18, 2025):

This is now addressed by https://github.com/apple/pkl/pull/1062.

The rewrites option allows Pkl to talk to a mirror server, rather than the original package host for downloading packages.

@bioball commented on GitHub (Jul 18, 2025): This is now addressed by https://github.com/apple/pkl/pull/1062. The rewrites option allows Pkl to talk to a mirror server, rather than the original package host for downloading packages.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
good first issue
help wanted
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#144
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?