port back to postgres.py

[chadwhitacre]

After lots of discussion on #129, we started porting to SQLAlchemy, but ran out of steam half-way through. We now have a mix of SQLAlchemy and the old postgres.py API, and (as @buttscicles pointed out in IRC) this mix is worse than either one or the other.

So do we finish the port to SQLAlchemy, or drop back to postgres.py? Rereading #129, the main reason to port to SQLAlchemy was to make it easier to contribute to Gittip, so that we could focus on growth.

Now, the bigger barrier to entry is Aspen, and we're not porting away from Aspen (#800). The reason we're not porting away from Aspen was best articulated by @dstufft:

TBH I find the most compelling reason for Gittip to be Aspen is you’ve stated it would kill your motivation ;)

That reasoning applies to the SQL vs. SQLAlchemy decision as well. SQLAlchemy is a drain on my motivation and productivity, and my personal productivity as a developer still matters at this stage.

Bolstered by Basho's experience with Erlang, I see the contributors argument as a red herring. The fact is that we have been able to find contributors who don't mind writing SQL. I'm thinking specifically of @buttscicles (ref), @alexcouper (ref), and @mw44118 (see #659 and #951). If we wanted to optimize for fungible contributors then we'd port to Rails or at least Django. But as @buttscicles points out, this "would be a lot of work and wouldn't magically create contributors." Porting to SQLAlchemy is a good bit of work as well, and we haven't finished it largely because those who were motivated to do the work have moved on (@mjallday and @joonas). I believe this illustrates the importance of optimizing for my motivation, since for the foreseeable future, I'm still gonna be here even when someone else moves on. In other words, we need to optimize for the contributors we actually have, starting with me.

As @matin reminded us on #129 (comment), the framing concern here is growth. For Gittip to grow, we need to catalyze small, fluid teams of long-term contributors that can iterate efficiently on Gittip products. Team Gittip is aimed at this challenge, and it's working: @strand has started contributing again because of Team Gittip, for example—his comment on #836 (comment) triggered this ticket. @gwenbell is diving in head-first. @rummik has responded positively as well.

My role is to make the developer experience as nice as possible for those actually working on Gittip. @strand, @gwenbell, @rummik, etc. are my customers. However, in order to fullfil my role, I have to be proud of and excited about and believe in the technical infrastructure of Gittip. I'm proud of postgres.py. I think it's awesome. And the fact is that using raw SQL via the postgres.py module is a legitimate technical decision: SQL vs. ORM is a holy war. Therefore, I propose that, because of me, we should port fully back to postgres.py.

[joealcorn]

+1

[clone1018]

My opinion is use what works, if it isn't broken you probably don't need to fix it :p

[chadwhitacre]

Ping @gwenbell @rummik (since I maxed out my cc: limit in the original :-) ).

[sigmavirus24]

@whit537 you can also set up teams with different people on them and then do @:orgname/:teamname to notify that team. :)

[chadwhitacre]

Ooh! Good call, @sigmavirus24. :)

[sigmavirus24]

11:39.08 < bruceadams> whit537: gh1146 sounds right to me (i can't +1 it quickly on github right now)

In other words I'm proxying @bruceadams 's 👍 for him. :)

[rummik]

I'm not really a fan of ORMs anyway. They tend to make it a pain to join tables (though I do like having some CRUD helpers for insert/upsert/update)

Of course, I don't really Python, so I'm not sure my opinion really matters here ^^;

[johana-star]

Stick with what whit537 is most comfortable with.

Let's remove SQLchemy.

[chadwhitacre]

I just factored out postgres.py:

https://postgres-py.readthedocs.org/en/latest/

See #1306 for migrating to that.

[zbynekwinkler]

Nothing more to do here, right?

[chadwhitacre]

Right, good catch @zwn.