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

multiple default_sources should have a configurable priority for automatic preferred_for behavior #42

Open
lamont-granquist opened this issue Feb 15, 2018 · 4 comments
Labels
Aspect: UX How users feel interacting with the project, focusing on function, ease-of-use and accessibility. Triage: Confirmed Indicates and issue has been confirmed as described. Triage: Feature Request Indicates an issue requesting new functionality. Type: Design Proposal Community survey of a proposal. Type: Enhancement Adds new functionality.

Comments

@lamont-granquist
Copy link
Contributor

The default behavior should not change, but users really want to be able to say "use all my :chef_repo cookbooks first, then use :supermarket second, and i don't want to tell you that my version of build-essentials should always take priority"

Right now that looks something like:

default_source :chef_repo, ./cookbooks” do |s|
  s.preferred_for *(Dir.entries(./cookbooks’) - [., ..] & self.run_list.map {|c| c.split(::).first})
end

The new DSL code should behave the same way so that if the :chef_repo takes priority over :supermaket then the presence of a build-essential-0.0.1 cookbook in the :chef_repo would take precedence over any version of build-essential in supermarket and there would be no crazy merging of actual versions -- presence of any version in a higher priority repo would knock out all versions in a lower priority repo.

@lamont-granquist
Copy link
Contributor Author

And I swear this is a dup of a conversation that I've had with @danielsdeleo before, but this one has a better title with SEO for the keywords I was trying to search on, plus it has the existing workaround.

@lamont-granquist
Copy link
Contributor Author

And the workaround obviously relies on ruby local pathing hacks so won't work for private-supermarket-overriding-public-supermarket or any other use case outside of :chef_repo I think.

@danielsdeleo
Copy link
Contributor

Yeah, if it's opt-in it's probably ok, especially since folks will just hack around it if we don't provide something. It would be extra awesome if we could detect in chef update if a cookbook moved from one default source to another and make that really clear. Or even have a mode where you have to explicitly allow cookbooks to move between sources, e.g.,

chef update
=> Error: you've been getting cookbook build-essentials from the public supermarket but now it's gonna come from private supermarket. Use `chef update --nah-its-fine` if this is cool
chef update --nah-its-fine
=> (success)

@danielsdeleo
Copy link
Contributor

In terms of hacks you could do with the current code, if you wanted one source to win for everything, I think this would work:

all_the_things = Object.new
def all_the_things.==(other); true; end
s.preferred_for all_the_things

But I haven't tried it so caveat emptor.

@tyler-ball tyler-ball transferred this issue from chef-boneyard/chef-dk Sep 30, 2019
@tyler-ball tyler-ball added Aspect: UX How users feel interacting with the project, focusing on function, ease-of-use and accessibility. Triage: Confirmed Indicates and issue has been confirmed as described. Triage: Feature Request Indicates an issue requesting new functionality. Type: Design Proposal Community survey of a proposal. Type: Enhancement Adds new functionality. labels Sep 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Aspect: UX How users feel interacting with the project, focusing on function, ease-of-use and accessibility. Triage: Confirmed Indicates and issue has been confirmed as described. Triage: Feature Request Indicates an issue requesting new functionality. Type: Design Proposal Community survey of a proposal. Type: Enhancement Adds new functionality.
Projects
None yet
Development

No branches or pull requests

3 participants