Clay, Apologies for the top post. Here's the current recommendation on dependencies - Answering your question on "I'm not acctually sure what the OpenStack policy is on dependency hygiene :D Anyway,": https://github.com/openstack/requirements#global-requirements-for-openstack-projects
There is a requirements team, you can reach them on the #openstack-requirements channel: https://wiki.openstack.org/wiki/Requirements -- Dims On Tue, Oct 11, 2016 at 1:23 AM, Clay Gerrard <[email protected]> wrote: > Greetings! > > Anyone have any experience to share positive or negative using > requests-mock? I see it's been used to replace another dependency that had > some problems in many of the OpenStack python client libraries: > > Added to global requirements -> https://review.openstack.org/#/c/104067 > Added to novaclient -> https://review.openstack.org/#/c/112179/ > Added to cinderclient -> https://review.openstack.org/#/c/106665/ > Added to keystoneclient -> https://review.openstack.org/#/c/106659/ > > But I'm not sure how folks other than Jamie are getting on with it? When > writing new tests do you tend to instinctively grab for requests-mock - or > do you mostly not notice it's there? Any unexpected behaviors ever have you > checking it out with bzr and reading over the source? Do you recall ever > having any bumps or bruises in the gate or in your development workflow > because of a new release from requests-mock? No presumed fault on Jamie! > It seems like he's doing a Herculean one-man job there; but it can be > difficult go it alone: > > https://bugs.launchpad.net/requests-mock/+bug/1616690 > > It looks like the gate on this project is configured to run nova & keystone > client tests; so that may be sufficient to catch any sort of issue that > might come up in something that depends on it? Presumably once he lands a > change - he does the update to global-requirements and then all of OpenStack > get's it from there? > > I ask of course because I really don't understand how this works [1] :D > > But anyway - Jamie was kind enough to offer to refactor some tests for us - > but in the process seems to require to bring in these new dependencies - so > I'm trying to evaluate if I can recommend requiring this code in order to > develop on swiftclient [2]. > > Any feedback is greatly appreciated! > > -Clay > > 1. As you may know (thanks to some recently publicity) swift & swiftclient > joined OpenStack in the time of dinosaurs with a general policy of trying to > keep dependencies to a *minimum* - but then one day the policy changed to... > *always* add dependencies whenever possible? j/k I'm not acctually sure > what the OpenStack policy is on dependency hygiene :D Anyway, I can't say > *exactly* where that "general policy" came from originally? Presumably > crieht or gholt just had some first hand experience that the dependencies > you choose to add have a HUGE impact on your project over it's lifetime - or > read something from Joel on Software - > http://www.joelonsoftware.com/articles/fog0000000007.html - or traveled into > the future and read the "go proverbs" and google'd "npm breaks internet, > again". Of course they've since moved on from OpenStack but the general > idea is still something that new contributors to swift & swiftclient get > acclimated to and the circle of confusion continues > https://github.com/openstack/swift/blob/master/CONTRIBUTING.rst#swift-design-principles > - but hey! maybe I can educate myself about the OpenStack policy/process; > add this dependency and maybe the next one too; then someday break the > cycle!?!? > > 2. https://review.openstack.org/#/c/360298 > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
