get rid of gittip.db global

[chadwhitacre]

We configure a db instance of the gittip module. That's a turd. We shouldn't have global state like that. Instead we should pass around the db instance to the various classes and functions that want it.

[zbynekwinkler]

It is going to be a lot of work. Is it worth it? Do you have some other reason besides "it would look nicer"?

[chadwhitacre]

@zwn Yeah, it'll take some work. Now is the time, though, with our focus on infrastructure.

This will make our code easier to read and maintain, and it will make our test suite better. For example, right now Participant.get_giving_for_profile takes a db argument for testing purposes but we fall back to the global version. That's a mess.

[zbynekwinkler]

It also complicates sphinx build (see IRC).

[chadwhitacre]

We have other global configuration but db is particularly egregious.

[zbynekwinkler]

What would be the best strategy to do this? Currently we have gittip.db but we also have website.db with the same thing. Where does website come from? configure-aspen.py seems to be using that var as a global object but it is not imported from anywhere in that file. Is that some aspen magic? Actually I'd rather be able to import modules without the side effect of connecting to the db with the credentials taken from the environment.

Is really the problem the existence of the gittip.db global or the way it is magically setup by importing a module that the user code has no control of?

I am asking because it relates to #1549. I'd like to wrap access to the db for that.

[chadwhitacre]

Where does website come from? configure-aspen.py seems to be using that var as a global object but it is not imported from anywhere in that file. Is that some aspen magic?

Yes. :-(

Actually I'd rather be able to import modules without the side effect of connecting to the db with the credentials taken from the environment.

configure-aspen.py is exec'd, not imported. Are you looking to import configure-aspen.py in another context, or ... ?

[zbynekwinkler]

Sphinx imports it.

The website is global to aspen.wsgi.website? So configure-aspen.py is like configuration file and that is why it is exec'd and not imported? I am not looking to import it - I am just wondering how it works. I would have been looking for a wsgi-compatible class within the gittip module, importing all needed stuff from aspen. Having all this setup code in its init method wouldn't have surprised me at all. The current way is a bit non-obvious. Having it setup that way would also allow different setup code for testing easily.

[chadwhitacre]

What does Sphinx import? gittip.db?

I am just wondering how it works.

@pjz and I talked this morning about making Aspen work more like you describe. For now there's an aspen script that instantiates a Server object, which in turn instantiates a Website object. This Website object subclasses a Configuration object, and it's in there that configure-aspen.py gets exec'd upon instantiation.

I feel like I'm not helping, though. Can you describe the immediate symptom you're dealing with? Sphinx doesn't like gittip.db?

[zbynekwinkler]

What does Sphinx import?

configure-aspen.py, actually it imports everything it finds.

I feel like I'm not helping, though. Can you describe the immediate symptom you're dealing with?

Nothing immediate. Just wondering how it works in general and what should be the way forward with gittip.db since it affects #1549.

[chadwhitacre]

configure-aspen.py, actually it imports everything it finds.

configure-aspen.py shouldn't be importable, since it has a - in the name. No?

... and what should be the way forward with gittip.db since it affects #1549.

My half-formed intention has been to use it exclusively from website.db and never from gittip.db. Step one on this ticket would be dropping back to website.db wherever website is in fact available. However, presumably db was stored globally on gittip in the first place because there's some place where we want to make db calls but website isn't available. I suppose the options in those cases are to rework our APIs to pass around website, or (better?) to pass around db.

[zbynekwinkler]

@whit537 It can be done. I have a part of this in ae99d63. What is missing is elsewhere accounts. We have this stalled elsewhere refactor. Should I just go ahead and get this done even in elsewhere code?

[chadwhitacre]

Should I just go ahead and get this done even in elsewhere code?

@zwn Yes. Thanks.

[zbynekwinkler]

@whit537 Done in 9f312d2. Continue in #1734.