Skip to content

Add a .gitignore file to each __pycache__ folder #141081

Description

@gvanrossum

Feature or enhancement

Proposal:

When creating a __pycache__ folder, add a .gitignore file with the content

# Created by CPython
*

I've seen this pattern appear in a few places (coverage.py's htmlcov folder, .venv, .pytest_cache) and it saves projects from having to add such things to their main .gitignore.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

Activity

  1. serhiy-storchaka commented on Nov 6, 2025

    @serhiy-storchaka
    Member

    Is not __pycache__ in a single top-level .gitignore file enough?

  2. hugovk commented on Nov 6, 2025

    @hugovk
    Member

    Similarly, we added a .gitignore to venv dirs in 3.13: #83417.

  3. gvanrossum commented on Nov 6, 2025

    @gvanrossum
    MemberAuthor

    Is not __pycache__ in a single top-level .gitignore file enough?

    But that would have to be added by every user for every repo.

    I would like the repo .gitignore to be about artifacts of the software in the repo, not artifacts of tools if we can avoid it.

  4. zware commented on Nov 6, 2025

    @zware
    Member

    Creating it ourselves also sends a clear signal that you really shouldn't be checking this stuff in.

  5. brettcannon commented on Nov 6, 2025

    @brettcannon
    Member

    My biggest question is how do we document this (I'm sure someone somewhere is checking in their __pycache__ files on purpose)? I'm assuming we will tweak this as we just deem reasonable based on whatever VCS is most popular at the time, but we should be clear in the docs that what's supported can change and there won't be any warning beyond What's New.

  6. gvanrossum commented on Nov 6, 2025

    @gvanrossum
    MemberAuthor

    Did we update any docs for the venv module when we added the same thing there?

    Is __pycache__ documented at all? Wherever that is, is where the docs should be updated for this.

  7. hugovk commented on Nov 7, 2025

    @hugovk
    Member

    Did we update any docs for the venv module when we added the same thing there?

    We added a --without-scm-ignore-files flag and a scm_ignore_files parameter and documented those:

    Although the What's New is the best overview:

    Did we update any docs for the venv module when we added the same thing there?

    Is __pycache__ documented at all? Wherever that is, is where the docs should be updated for this.

    It's mentioned on a dozen pages but doesn't seem to have its own "home":

    Perhaps this would be a good place to put it:


    There's a PR up at #141162.

  8. nanonyme commented on Nov 7, 2025

    @nanonyme

    This sounds like unnecessary noise for things like container images. There are tons of repository templates including in GitHub which will initialize your repo with top-level .gitignore for Python.

  9. nanonyme commented on Nov 7, 2025

    @nanonyme

    If this is done, please make it opt-outable at least. I am quite surprised also to hear that venv went ahead with this feature.

  10. hugovk commented on Nov 7, 2025

    @hugovk
    Member

    It's opt-out for venv using --without-scm-ignore-files:

    https://docs.python.org/3/library/venv.html#cmdoption-venv-without-scm-ignore-files

  11. nanonyme commented on Nov 7, 2025

    @nanonyme

    I was referring to if adding this became a Python default, not just venv. There should really be an opt-out.

  12. brettcannon commented on Nov 7, 2025

    @brettcannon
    Member

    I was referring to if adding this became a Python default, not just venv. There should really be an opt-out.

    This is a bit off-topic for this issue. If you want to propose reverting the default behaviour for venv then please open another issue.

  13. 17 remaining items

  14. serhiy-storchaka commented on Dec 8, 2025

    @serhiy-storchaka
    Member

    I think we are overthinking it. The content of __pycache__ is an implementation detail. It was already changed in the past (from .pyc and .pyo to .cpython-315.opt-2.pyc) and depends on the Python version, so if you use the same source tree with different Python versions it can be full of abandoned stuff). Simply, either add .gitignore, or don't.

    I don't think adding it will help much, but it will not harm. If you worry about disk space, you should seriously consider precompiling bytecode and packing it in a zip file (even without compression it will save a lot of space for small files).

  15. brettcannon commented on Dec 12, 2025

    @brettcannon
    Member

    I think we are overthinking it.

    I think I agree.

    Any core devs against merging w/o an opt-out and seeing how it goes during the alpha and beta phases?

  16. gpshead commented on Dec 13, 2025

    @gpshead
    Member

    yeah lets just see how it goes.

  17. gpshead commented on Dec 13, 2025

    @gpshead
    Member

    and have release manager @hugovk promote it in release notes asking people to pipe up if it causes problems and make the final call based on any feedback before the RC phase.

  18. added a commit that references this issue on Dec 15, 2025
  19. hugovk commented on Dec 15, 2025

    @hugovk
    Member

    This will be in tomorrow's 3.15.0a3, is called out in What's New's release highlights and I'll also put this in the release notes:

    Thanks all!

  20. gvanrossum commented on Dec 15, 2025

    @gvanrossum
    MemberAuthor

    Thanks all indeed!

  21. hugovk commented on Dec 15, 2025

    @hugovk
    Member

    Re-opening.

    Buildbots failed after merging the PR: #141162 (comment)

    test_with_pip (test.test_venv.EnsurePipTest.test_with_pip) ... FAIL
    
    ======================================================================
    FAIL: test_with_pip (test.test_venv.EnsurePipTest.test_with_pip)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/buildbot/buildarea/3.x.itamaro-centos-aws.nogil/build/Lib/test/test_venv.py", line 1047, in test_with_pip
        self.do_test_with_pip(False)
        ~~~~~~~~~~~~~~~~~~~~~^^^^^^^
      File "/home/buildbot/buildarea/3.x.itamaro-centos-aws.nogil/build/Lib/test/test_venv.py", line 1023, in do_test_with_pip
        self.assert_pip_not_installed()
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
      File "/home/buildbot/buildarea/3.x.itamaro-centos-aws.nogil/build/Lib/test/test_venv.py", line 906, in assert_pip_not_installed
        self.assertEqual(out.strip(), "OK")
        ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
    AssertionError: '' != 'OK'
    + OK

    The problem was that when pip uninstalls itself, it removes its own files, and then tries to remove empty directories like __pycache__. But __pycache__ contains our .gitignore so the dir removal fails.

    #142745 is a possible fix to not add .gitignore in site-packages dirs, and let the package managers handle those.

    However, it hardcodes site-packages. We should maybe use sysconfig.get_path('purelib') instead in case the user has reconfigured to use something else, such as dist-packages in Ubuntu, but we can't import sysconfig in _bootstrap_external.py because it's too early and can result in a circular import.

    But as @encukou asks:

    More generally: how can you tell what “manages” a given directory? I don't really have an answer, I'm afraid.

    Thoughts?


    RM hat: we may need to revert this for tomorrow's a3 so we have more time for this.

  22. reopened this on Dec 15, 2025
  23. added a commit that references this issue on Dec 15, 2025
  24. brettcannon commented on Dec 15, 2025

    @brettcannon
    Member

    But as @encukou asks:

    More generally: how can you tell what “manages” a given directory? I don't really have an answer, I'm afraid.

    Thoughts?

    At what directory level? Virtual environment (which Alyssa has an idea)? All installed projects? Each installed project?

  25. added a commit that references this issue on Dec 15, 2025
  26. added 2 commits that reference this issue on Dec 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytopic-importlibtype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions