New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testsuite does not pass #96

Closed
sqlalchemy-bot opened this Issue Jan 4, 2013 · 17 comments

Comments

Projects
None yet
1 participant
@sqlalchemy-bot

sqlalchemy-bot commented Jan 4, 2013

Migrated issue, originally created by Anonymous

see attached log


Attachments: test.result.log | local_alembic_test.log

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 4, 2013

yaccz (@yaccz) wrote:

Neither does 0.4.0, 0.3.6, 0.3.5, 0.3.4

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

Michael Bayer (@zzzeek) wrote:

log using a fresh install of all required software

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

Changes by Michael Bayer (@zzzeek):

  • attached file local_alembic_test.log
@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

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

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

Michael Bayer (@zzzeek) wrote:

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

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

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

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

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

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

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

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

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

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

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

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

Changes by Michael Bayer (@zzzeek):

  • changed status to reopened
@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

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

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

Michael Bayer (@zzzeek) wrote:

44a6117

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 5, 2013

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 6, 2013

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

This comment has been minimized.

sqlalchemy-bot commented Jan 11, 2013

Michael Bayer (@zzzeek) wrote:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment