You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The next major release of Berkshelf should break the ability of berkshelf to resolve circular dependencies when using the gecode solver. Molinillo will never support circular dependencies, nor should it. This creates a blocker to people who have circular dependencies to stay on Berkshelf, using only gecode, which is a system that we more or less no longer actively support, and blocks migrations to PolicyFiles, and some community cookbooks which have circular deps work on Berks but fail on PolicyFiles.
Circular dependencies also cause performance issues, particularly with the way that circular deps don't just create single circular deps but with N versions of cookbook A that depend on M versions of cookbook B on the server there will be NxM circular deps that the solver needs to deal with. As you add more cookbook and their versions into the mix the cartesian product of all the cookbook versions quickly explodes. Our gecode implementation is optimized for checking the lastest of all versions and in the absence of constraints this is fast. However, when you start mixing in cookbooks that have e.g. 1.x and 2.x versions and some cookbooks are
pinning with semver style pins instead of floating on latest the problem will scale badly. This problem gets even worse when it comes to the error renderer in our gecode implementation that is written in ruby.
The solution is that circular deps need to end. Cookbooks with circular deps either need to be merged into one cookbook (because there's actually only one concern) or else they need a third fascade cookbook created which deps on both of them and extracts the cross-cookbook bits from at least one of the cookbooks up a level (or some other appropriate design pattern).
This is one example of a person being pushed away from PolicyFiles and selecting the wrong answer (Berkshelf) because of circular dependencies:
The next major release of Berkshelf should break the ability of berkshelf to resolve circular dependencies when using the gecode solver. Molinillo will never support circular dependencies, nor should it. This creates a blocker to people who have circular dependencies to stay on Berkshelf, using only gecode, which is a system that we more or less no longer actively support, and blocks migrations to PolicyFiles, and some community cookbooks which have circular deps work on Berks but fail on PolicyFiles.
Circular dependencies also cause performance issues, particularly with the way that circular deps don't just create single circular deps but with N versions of cookbook A that depend on M versions of cookbook B on the server there will be NxM circular deps that the solver needs to deal with. As you add more cookbook and their versions into the mix the cartesian product of all the cookbook versions quickly explodes. Our gecode implementation is optimized for checking the lastest of all versions and in the absence of constraints this is fast. However, when you start mixing in cookbooks that have e.g. 1.x and 2.x versions and some cookbooks are
pinning with semver style pins instead of floating on latest the problem will scale badly. This problem gets even worse when it comes to the error renderer in our gecode implementation that is written in ruby.
The solution is that circular deps need to end. Cookbooks with circular deps either need to be merged into one cookbook (because there's actually only one concern) or else they need a third fascade cookbook created which deps on both of them and extracts the cross-cookbook bits from at least one of the cookbooks up a level (or some other appropriate design pattern).
This is one example of a person being pushed away from PolicyFiles and selecting the wrong answer (Berkshelf) because of circular dependencies:
https://stackoverflow.com/questions/62439333/is-it-possible-to-use-both-berksfile-and-policyfile-at-the-same-time-in-a-chef-c?noredirect=1#comment111606366_62439333
That is basically what we do not want new people ever doing.
The text was updated successfully, but these errors were encountered: