New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency mirroring RFC #420
Comments
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
But, we wouldn't implement this if HTTP proxying is good enough. |
HTTP proxy is not good enough, unfortunately |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #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, #354) and for each dependency of my project
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!
The text was updated successfully, but these errors were encountered: