Testsuite does not pass

[sqlalchemy-bot]

Migrated issue, originally created by Anonymous

see attached log

---

Attachments: test.result.log | local_alembic_test.log

[sqlalchemy-bot]

yaccz (@yaccz) wrote:

Neither does 0.4.0, 0.3.6, 0.3.5, 0.3.4

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

log using a fresh install of all required software

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• attached file local_alembic_test.log

[sqlalchemy-bot]

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.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

the issues listed occur when testing against older SQLAlchemy versions only.

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• changed status to closed

[sqlalchemy-bot]

yaccz (@yaccz) wrote:

1. running with nosetests yields the same results
2. Can you add the jenkins link to README or somewhere, I could not find it.
3. so alembic 0.4.1 supports only SA >= 0.8?

[sqlalchemy-bot]

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):
File "/var/tmp/portage/dev-python/alembic-0.4.1/work/alembic-0.4.1/tests/test_autogenerate.py", line 964, in test_render_fk_constraint_kwarg
autogenerate._render_constraint(fk, self.autogen_context),
File "/var/tmp/portage/dev-python/alembic-0.4.1/work/alembic-0.4.1/alembic/autogenerate.py", line 593, in _render_constraint
return renderer(constraint, autogen_context)
File "/var/tmp/portage/dev-python/alembic-0.4.1/work/alembic-0.4.1/alembic/autogenerate.py", line 640, in _render_foreign_key
apply_metadata_schema = constraint.parent.metadata.schema
AttributeError: 'ForeignKeyConstraint' object has no attribute 'parent'

[sqlalchemy-bot]

idella5 (@idella5) wrote:

Are you declaring this resolved? Two points.

1. If it designed to run tests with setup.py. it should be able to run tests with setup.py test. It appears to yield

SKIP: Can't connect to database: (OperationalError) could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
could not create socket: Address family not supported by protocol
None None
SKIP: Can't connect to database: (OperationalError) (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)") None None

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'.

[sqlalchemy-bot]

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.

[sqlalchemy-bot]

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.

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• changed status to reopened

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

SKIP: Can't connect to database: (OperationalError) could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432? could not create socket: Address family not supported by protocol None None SKIP: Can't connect to database: (OperationalError) (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)") None None

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.

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.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

44a6117

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• changed status to closed

[sqlalchemy-bot]

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.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

Issue #100 was marked as a duplicate of this issue.