Skip to content
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

Fallback/passthrough for private depot dependencies #19

Closed
elliott-davis opened this issue Jan 25, 2018 · 1 comment
Closed

Fallback/passthrough for private depot dependencies #19

elliott-davis opened this issue Jan 25, 2018 · 1 comment

Comments

@elliott-davis
Copy link
Contributor

@jtimberman commented on Fri Apr 07 2017

Scenario: I have a private Habitat depot where I want to publish my application, acme/myapp. This application is written in Ruby on Rails, and I want to use the core packages as dependencies without rebuilding them or mirroring the public depot to my internal one. I'm okay with my application nodes talking to the public depot, so I would like to use it as a fallback for any packages that can't be found locally.

I propose adding a command-line option to hab pkg install that will use a fallback URL as the depot for missing packages. This option would have a corresponding ENV variable so it wouldn't need to be specified. So for example, if I do:

hab pkg install acme/myapp --url https://private-depot.example.com/v1/depot --fallback-url https://willem.habitat.sh/v1/depot

It would download acme/myapp from my private depot, private-depot.example.com/v1/depot, and any dependencies such as core/ruby or core/glibc from willem.habitat.sh/v1/depot.

I think the "sane default" is for this fallback URL to use the public depot. Perhaps a CLI option and ENV variable to disable this for air-gapped environments that can't talk to the internet.


@jtimberman commented on Fri Apr 07 2017

Longer term we will want to implement "pull through proxy" and federation to replace this, but this is fine for an initial spike.


@eeyun commented on Tue Apr 11 2017

There will certainly come a point where we're going to need to answer this use-case. For now we're going to flag this as help wanted as we have some other work that would supersede being able to start on this.

@raskchanky
Copy link
Contributor

We are actively working on officially supported on-prem depots right now. That work is happening here. That is a private repo for now, but will most likely be open-sourced at some point. Additionally, there is work in progress here to support pulling packages from an upstream depot if your default depot doesn't contain said packages. Both of those should address this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants