Testsuite does not pass #96
Comments
yaccz (@yaccz) wrote: Neither does 0.4.0, 0.3.6, 0.3.5, 0.3.4 |
Michael Bayer (@zzzeek) wrote: log using a fresh install of all required software |
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: the full suite of tests requires the latest SQLAlchemy 0.8 to pass completely. See the attached log. The "atexit" error at the end is as far as I can tell a bug in distutils or in how distutils interact with nose. Alembic tests should generally be run via "nosetests" directly to avoid side effects like this. Alembic's tests are subject to continuous integration as you can see here: http://jenkins.sqlalchemy.org/job/alembic-default-sqla-default-2.7/ http://jenkins.sqlalchemy.org/job/alembic-default-sqla-default-3.2/ so if the tests are failing, we definitely know about it. |
Michael Bayer (@zzzeek) wrote: the issues listed occur when testing against older SQLAlchemy versions only. |
Changes by Michael Bayer (@zzzeek):
|
yaccz (@yaccz) wrote:
|
yaccz (@yaccz) wrote: So I tested with latest sqlalchemy 0.7.9 and I'm getting only one failure ERROR: test_render_fk_constraint_kwarg (tests.test_autogenerate.AutogenRenderTest)Traceback (most recent call last): |
idella5 (@idella5) wrote: Are you declaring this resolved? Two points.
SKIP: Can't connect to database: (OperationalError) could not connect to server: Connection refused which is quite fixable, though not for me but hopefully you can. Running background server provesses in tests in gentoo is generally 'tricky' and prone to tests trippping over it. 2.) nosetests is a worthy alternative, and it also yeilds the 'ForeignKeyConstraint' object has no attribute 'parent' euscan indicates that the version of sqlalchemy latest available to be 0.7.9. This beckons the question, what is going on with testing alembic against a version not yet released, deadending the test suite to a failure, albeit but 1 single test???? It means I don't have the option of bumping sqlalchemy to un unreleased version. At a pinch it's feasible to skiptest the test that demands an attribute absent in its dependant package for the sake of seeing the test suite pass, but you can understand, I assume that's, bending the rules to a point of a clear 'snap'. |
yaccz (@yaccz) wrote: "sqlalchemy latest available to be 0.7.9. This beckons the question, what is going on with testing alembic against a version not yet released, " Well, there are released sqlalchemy 0.8 betas but I agree with your point. "SKIP: Can't connect to database:" I don't think this is something upstream can fix. |
Michael Bayer (@zzzeek) wrote: I think you're making a little bit of a bigger deal than this is (note: referring to idella2's somewhat rambling message), but fine, I will add SkipTest directives today. Also 0.8.0b2 is available on cheeseshop and is the default version that tools like "pip" will install, if you look at the log I attached. |
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote:
I don't see the error there ? it's seeing that you don't have your DB running and it's skipping the test. It is actually designed to check if a particular DB is present, and if not, hey we can't run the test ! it's skipped. As opposed to failing - which is not correct, because without that DB running, that particular test can't run, hence it can't fail. |
Changes by Michael Bayer (@zzzeek):
|
idella5 (@idella5) wrote: ok I follow. If it's being skipped conditionally then that's fine, I hadn't picked that up clearly. Point 1) yaccz is preparing an ebuild of alembic for addition to portage, making it necessary to meet gentoo's basic P.M. requirements. Tests failing is itself contraversial in gentoo, but currently the capacity to 'excuse' a package from a couple of minor testsuite fails has been cast aside in the change to a new set of eclasses that direct an emerge, making it a case of all or nothing. It's my place to guide the making of the ebuild and finally commit it on behalf of yaccz, which I (and no-one else) am offering to do. Point 2. "Also 0.8.0b2 is available on cheeseshop and is the default version that tools like "pip" will install" The preference of the python lead, and not my own, is to frown and baulk at alpha and beta versions, but await the version release, not my call. 'pip' is an alternate package manager to portage's emerge, and therefore in gentooland has, neither right of place nor relevance since it counters the nature of portage. |
Migrated issue, originally created by Anonymous
see attached log
Attachments: test.result.log | local_alembic_test.log
The text was updated successfully, but these errors were encountered: