Open Stack

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 <clay.gerrard at gmail.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims