pytest-dev / pytest-dev/pytest

[perf] Automatically prefer Windows Dev Drive for default tmp_path

Open
#11,040 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

platform: windows type: performance type: proposal
Dominant language
Python
Stars
14.5k
Forks
3.4k
Avg merge
2d 9h
Merged PRs (30d)
35

Description

What's the problem this feature will solve?

Windows Dev Drive is a new OS feature that allows users to create a high performance disk that's designed for development activities. The performance improvement is based on new optimisations to the file system driver, and separating it out from the default OS drive reduces other overheads.

It's perfect for storing temporary files, however, it was decided that it's not safe for Windows to redirect all TEMP accesses to a Dev Drive by default. But our testing showed the improvements get significantly better when you do it, and we believe apps that can switch ought to switch.

I was part of the design team for this feature, so happy to add as much more context as you'd like and as I'm able to. Obviously these are public statements, so I have to be careful about things that might be interpreted as promises and not merely dreams, hopes and ambitions 😉

Describe the solution you'd like

Currently PyTest has ways for callers to redirect where temp files are stored, but I'd like to propose it could detect that the current project (or environment, or CWD, or something, I'm not so fussy about it) is on a Dev Drive, and if so, create a temp directory on that same drive.

I'm in the process of adding an os.path.isdevdrive function to CPython for 3.12, so would love to hear whether this is something you'd consider using, and whether a simple test like this suits your needs.[^1]

The kind of logic I'd expect to see (around here):

from_devdrive = None
if not from_env and hasattr(os.path, 'isdevdrive'):
    # passing through "tbd_project_root" is TBD
    root = ''.join(os.path.splitroot(self.tbd_project_root)[:2]) # get 'D:\\' or equivalent path
    if os.path.isdevdrive(root):
        from_devdrive = os.path.join(root, '.pytest-temp')
temproot = Path(from_devdrive or from_env or tempfile.gettempdir()).resolve()

isdevdrive will work on the full path, but I strip back to the drive name first because it could change which drive is actually used (e.g. the project might be in a mounted directory). There's not really an efficient way to handle this case, and on balance it makes the most sense to just ignore the optimisation anyway (access through a mounted directory is typically slow).

Obviously this can only light up in 3.12 and not earlier (unless you want to port the code into ctypes, which I'll understand if you don't bother). Dev Drive doesn't become widely available until the end of the year anyway, so 3.12 will also be available. Just another reason for people to upgrade! 😄

Alternative Solutions

An alternative would be to detect and suggest to users that since their code is on a Dev Drive, they should also manually provide the setting to store temporary files on it as well. I'm quite okay with this as an approach, and it might make more sense anyway (especially as a path towards changing the default in some unspecified future).

Another alternative would be to merely document it. I'd be disappointed by this, because we really want the fact that a Dev Drive is being used to be the signal that dev-related files should be stored there, and we don't want to encourage users to set global environment variables for something like this. It also seems unlikely to be discovered by existing users, who probably aren't going back to read this documentation regularly.

Python 3.12 already has os.listdrives(), so there is the possibility of searching for a Dev Drive. I don't think you'd want to go down this path though, unless there's genuinely no usable info about where the user is currently working. If they've got a Dev Drive but aren't using it, they probably have a good reason and we should leave them alone.

Additional context

If you prefer video demonstrations: https://build.microsoft.com/en-US/sessions/7ed9bb72-b4f4-4490-9b26-911d1ac263d1?source=/home

The docs again: https://learn.microsoft.com/en-us/windows/dev-drive/

Right now it's available on the Dev Channel of Windows Insider, which means it is public and people are trying it out. Python and Pytest was one of the key scenarios we were testing during development, so it'd be awesome to have it be the best it can.

[^1]: Obviously we're past the first beta, but I got an allowance to add it before beta 2 (next Tuesday!) because of NDAs surrounding the feature.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/_pytest/tmpdir.py around line 161 and review how the current project or environment determines the temporary-file root. Check how Python 3.12's os.path.isdevdrive could select a same-drive .pytest-temp directory while preserving explicit environment settings and compatibility with earlier Python versions. Done means the intended Windows Dev Drive behavior and its fallback rules are settled and covered by the relevant existing tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
performance, testing-qa
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.