3.10.0: Testing fails with some other Python module installed #99
Comments
|
What command are you using to initiate the tests? I'm struggling to replicate this. |
|
Based on the errors you're seeing, even after adding the pkg_resources thing you're either not changing directories to the build dir Or something is wrong with your Makefile handling perhaps? suggests that something is not getting expanded on your side of the processing: paste doesn't know what |
|
I modified the output of test and replaced the actual path by |
|
The full command to run tests is this: |
|
And with the above command I get this result: |
|
If I run a similar version of your command things work fine for me: leading to: Is your If I downgrade to your version of pytest, things still work. If I downgrade to python 3.9.19 they also work then. Based on searching around you might have some luck by upgrading setuptools and/or importlib_metadata I know you're probably thinking "but it used to work, now it doesn't!" and I sympathise but unless I'm able to replicate the problem I can't gain any more insight into what's going on. Please report back here if you learn anything more. |
|
The Anyway, I tried this directly in the unpacked sdist: and it still fails. Even without Now we just need to find what one is causing the issue. I tried to uninstall/disable all And yes, it is exactly: "it used to work and now it does not". :-) If I try to run tests for 3.9.0 then everything works, but with 3.10.0 it fails. Please note that otherwise the testing machine is unchanged: |
mtelka
changed the title
PYTHONPATH
|
I would guess that it is conflicting with one or both of: try In general, however, you really want to be doing package builds in a virtualenv so your environment is not infected by installed packages. If I install Paste==3.9.0 into my environment, I can replicate your failure. Can you try the following in your environment and let me know where that gets you? diff --git a/tests/__init__.py b/tests/__init__.py
index cafcf8a..f07735e 100644
--- a/tests/__init__.py
+++ b/tests/__init__.py
@@ -1 +1,8 @@
"""Tests for Paste"""
+import sys
+import os
+
+sys.path.insert(0, os.path.dirname(os.path.dirname(__file__)))
+
+import pkg_resources
+pkg_resources.require('Paste')If that fixes it, or fixes it except for a failure with Then I've got a pretty good idea on how to clean things up to get stuff back to a state where it works for you. Is bedtime for me, so I won't be responding for a few hours. We've got two ways to go here:
Both may be good ideas. Let me know what you discover with the patch, and what you think about the rest of it. |
I found that I need to uninstall both
Testing in virtual env while packaging makes no sense for us since the package will be running in the real environment once installed, not in a virtualized one and so we need to make sure it runs properly while installed so we need to test in real environment. Testing in a virtual environment won't find interoperability issues (like this one :-)).
As I wrote in #99 (comment) the
The problem is also there when no other Anyway, why are
As I wrote above we test in real environment intentionally, so I'm very sorry this is not the way to go. What I can do here is that I can make sure there are no offending packages installed while testing
|
|
Oh, I don't refuse, we just needed to get all the details to figure out the right way to fix it. I've got enough info now to fix it, I think. Thanks for persevering. Will have a 3.10.1 within the next 24 hours or so. Regarding this:
It's because Paste is a "namespace package" and uses a deprecated way of managing that. A recent cleanup via a series of patches to try to clean up code made a variety of changes to how namespace packages are handled. The existing tests continued to work so it was assumed that everything still works. I'll add a test that creates an environment with the previous release of Paste (and maybe PasteDeploy) installed and that should show the way to a solution here and also keep any future releases guarded. And regarding this:
Me neither! See #91 |
Glad to see that ;-).
Just FYI, if the fix is going to be just in tests (and not in the core Paste) then I do not need a new Paste release with this testing issue fixed only (but if there is one, I won't complain :-)). Thank you. |
When we did a lot of recent Python2-isms cleanup recently it broke some tests when run in an environment where a previous version of paste, or one of the consumers of its namespace package, were already installed. This was probably done to quiet warnings. However, it hides issues with complex environments. In addition to fixing the problem, this change adds a tox test environment that should cause a failure if we introduce the error again. Fixes #99
|
If you could have a look at #100 and let me know if it is happy in your environment that would be great. It is a test only fix but I will likely release it just for cleanliness. |
* Cleanup namespace handling in tests When we did a lot of recent Python2-isms cleanup recently it broke some tests when run in an environment where a previous version of paste, or one of the consumers of its namespace package, were already installed. This was probably done to quiet warnings. However, it hides issues with complex environments. In addition to fixing the problem, this change adds a tox test environment that should cause a failure if we introduce the error again. Fixes #99 * remove skipsdist to see if that ensures namespace * update LICENSE per #101
I'm packaging Paste for OpenIndiana and during the package creation I run tests. Testing started to fail miserably with version 3.10.0:
It looks like the testing started to ignore the
PYTHONPATHvariable so it is unable to find thepastethat it is supposed to test.When I do this:
Then testing behaves far better and almost all tests pass, except this one:
The text was updated successfully, but these errors were encountered: