SQL alchemy file structure

[danielballan]

partial solutions to #4163

Merge this into the sql branch so we can start incorporating bug fixes into the new file structure of sql.py / sql_legacy.py.

[hayd]

failed travis should be fixed with a rebase :)

[danielballan]

Yeah, thanks. It's running now. What happened there, out of curiosity?

[cpcloud]

was a travis config issue my fault

[danielballan]

Good to go. We should merge #4304 into sql.py, legacy_sql.py, test_legacy_sql.py. test_sql.py is empty so far.

[cpcloud]

not sure, but i think #4163 will be closed when this is merge just note to self reopen it if it closes 😄

[jreback]

I think the issue only closes if you say 'closes' before the issue (I one had 'fixes' and nothing happened)

[cpcloud]

official docs for that (sort of) it's about commit message closing

[jreback]

@danielballan minor quibble....do we need sqlalchemy in all builds? things are so fast now almost doesn't matter

[danielballan]

I'm not sure. Are there docs on what builds do what? The versions of Python are obvious, but what is _LOCALE doing?

[cpcloud]

no docs really, i'll open an issue to doc them in the wiki, but the build stuff changes occasionally so need to remember to update that.

here's the short version

2.6 runs tests marked not slow WITHOUT full dependencies
2.7_LOCALE runs slow tests WITH full deps in a different locale (Chinese i think)
2.7 runs not slow WITH full deps (we unofficially call this the production build)
3.2 runs not slow WITH full deps (minus a few deps that just aren't py3k compat)
3.3 runs not slow WITH full deps same as above ^^^^

[jreback]

generally full deps are on
2.7,3.2 locale does the plotting stuff
2.6,3,3 are pretty bare
look at the print versions to see what is installed

[cpcloud]

@jreback 3.2, 3.3 are now running full deps

[jreback]

3.3 runs full deps?

[cpcloud]

yep

[jreback]

oh ok great

[danielballan]

I can remove sqlalchemy from 2.6 for consistency. Might as well run it to be sure we don't introduce 2.6 compat issues? Your call.

[hayd]

We could make it a soft dependency i.e. skip tests if SQLalchemy (or MySQL etc.) installed or if there is a connection faiiure (with anything other than SQLite)?

At the moment:

• test_sql is empty, I'll quickly tweak the test_sql I put together a couple of weeks ago (to use SQLite BUT I won't yet use SQLAlchemy notation (but that needs to be done to avoid writing lots of dialect specific tests), but that should be done very shortly). Could you then cherry-pick before we merge into master? I don't think we can put this into master completely untested.
• should update 0.13 release notes that sql has been moved to sql_legacy, and sql will be used for sqlalhemy.

[jreback]

don't merge quite yet
waiting for Wes to cut the release

[danielballan]

@hayd Yes, I agree sqlalchemy should be a soft dependency, just as MySQLdb is now. Can we merge all these commits into the sql branch but none into the master?

[jreback]

yes.....can merge to sql branch no prob (@hayd)

[hayd]

Updated sql branch, go for it!

[hayd]

closing in favour of merging sql branch later