-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Remove tests.lib.path #6050
Comments
A few issues:
Number 4 and similar issues with comparisons seem like they would be the biggest route for regressions to go unnoticed or invalid tests to be introduced in the future. |
Here's a mapping from the current class to equivalent functionality in
|
Filed #6700 for removing this. |
This only needs to be added to tests that would fail on directly switching this behavior. And, in those cases, I feel we should blanket-replace |
#6701 gets rid of |
The note was more regarding the functionality that should be added to the existing function to make it compatible, so we don't need to think about it when making the final switch. I assume we make the change, then add the assertion as you suggest for the tests that fail. |
Looking at our uses of abspath (searching To make sure my hypothesis was correct, I ran the tests with the following patch and everything passed. :) diff --git a/tests/lib/path.py b/tests/lib/path.py
index b2676a2e..8c2384a1 100644
--- a/tests/lib/path.py
+++ b/tests/lib/path.py
@@ -129,6 +129,9 @@ class Path(_base):
"""
'./a/bc.d' -> '/home/a/bc.d'
"""
+ import pathlib
+ assert pathlib.Path(self).resolve() == pathlib.Path(self).absolute()
+
return Path(os.path.abspath(self))
def resolve(self) |
Working on a PR to remove the |
The benefit of |
@chrahunt Yep. I found "13 results in 6 files", which isn't much overhead, given that we're spawning subprocesses and doing network requests. :) |
Hi @pradyunsg Now that @gutsytechster in working on #7869 to divide it into smaller PRs (1 PR just for helper functions, and maybe 2-3 PRs to replace the asserts with the helper functions). How would I go about then to work on this issue from another angle, perhaps breaking down #7860 in smaller PRs too. I am guessing once the helper function gets merged in, it's a good idea to take a few test files at a time per PR, replace the usage of Any other suggestions on the approach to proceed with this issue is also welcome. |
@deveshks take a look here, where @chrahunt talks about what-to-do-next here (if you haven't seen it already) made a list of next-steps for this and talks about the general approach to take here. While the aforementioned PR (#7689) is aimed at solving 4, we'd still want to work on 2 and 3 prior to going in and replacing the test suite's usage to pathlib. |
Thanks for this, perhaps I can start by tackling 3, but I am not very clear on what changes need to be done there? What I got from the description was that since the I tried something like this with diff --git a/tests/lib/__init__.py b/tests/lib/__init__.py
index f51cce1e..b3a6ec66 100644
--- a/tests/lib/__init__.py
+++ b/tests/lib/__init__.py
@@ -433,8 +433,6 @@ class PipTestEnvironment(TestFileEnvironment):
verbose = False
def __init__(self, base_path, *args, **kwargs):
- # Make our base_path a test.lib.path.Path object
- base_path = Path(base_path)
# Store paths related to the virtual environment
venv = kwargs.pop("virtualenv")
@@ -462,8 +460,8 @@ class PipTestEnvironment(TestFileEnvironment):
)
# Create a Directory to use as a scratch pad
- self.scratch_path = base_path.joinpath("scratch")
- self.scratch_path.mkdir()
+ self.scratch_path = os.path.join(base_path, "scratch")
+ os.mkdir(self.scratch_path)
# Set our default working directory
kwargs.setdefault("cwd", self.scratch_path) |
Changes like that look good to me. Not everything is gonna be as simple as I'm pretty sure you'll need to test on all supported versions since path-related stuff has had some incremental changes in the past few Python releases IIRC. |
But this means that we got rid of a functionality supported by
Agreed, I guess the only way to do that is to let the tests run through our CI? |
Or... you could run tests on all platforms, across multiple Python versions locally. :P |
Unfortunately I only have access to a Mac. I was also interested in knowing if the end goal of 3 is to get rid of a functionality supported by |
Honestly, I'm not a 100% sure myself what the answer is, so I'm picking the option of "we need to figure it out". :) |
No worries, let me get the ball rolling on 3 via a PR, I will first aim to just contain the changes in tests/lib/* without changing the tests itself, and see how far we can go from there to "figuring it out" :) |
@ssurbhi560 @gutsytechster Thank you for tackling this together, collaborating on who-does-what, and creating some really nicely scoped PRs that were easy to review! ^>^ I've gone ahead and reviewed all of them (I think?). Let me know if I've missed any. I'll wait a couple of days, in case someone else wants to review them / y'all want to address any of the non-blocker comments on the PRs eagerly. :) |
Thank you @gutsytechster @ssurbhi560 |
If this work continues someone will have to step in and maintain pathlib2 until pip too drops support for python2 |
@hexagonrecursion Pip has dropped support of Python 2, so I'm not sure what you're suggesting here... |
Well, appreciate the reminder. #9578 filed, and I'll wrap this up there. There's a couple of loose ends, but should be easy enough for a weekend morning. :) |
This is done |
File: https://github.com/pypa/pip/blob/master/tests/lib/path.py
There exist better alternatives to rolling out our own "Path" class for file handling -- the stdlib pathlib.Path and pathlib2.Path (backport to Py2) should be more than sufficient to satisfy our needs now.
To be done:
The text was updated successfully, but these errors were encountered: