Sitelet https://github.com/python/cpython/issues/54781
Skip to content

Move test sub-packages to Lib/test #54781

Description

@voidspace
BPO 10572
Nosy @warsaw, @brettcannon, @theller, @rhettinger, @terryjreedy, @abalkin, @benjaminp, @tarekziade, @ned-deily, @ezio-melotti, @merwok, @bitdancer, @voidspace, @berkerpeksag, @zware, @serhiy-storchaka, @pablogsal, @miss-islington, @erlend-aasland, @Leonardofreua
PRs
  • bpo-10572: Move test sub-packages to Lib/test #18524
  • bpo-10572: Move tkinter tests to /test #18727
  • bpo-10572 : Move sqlite3 tests to Lib/test/test_sqlite3 #24148
  • bpo-10572: Move sqlite3 tests to Lib/test #29304
  • bpo-10572: Add sqlite3 test back in PGO test suite #29327
  • Files
  • issue10572-sqlite3.patch
  • issue10572-lib2to3.patch
  • issue10572-sqlite3-2.patch
  • issue10572-lib2to3-2.patch
  • issue10572-sqlite3.diff
  • issue10572-ctypes.diff
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = None
    created_at = <Date 2010-11-29.00:52:57.129>
    labels = ['easy', 'type-feature', 'tests', '3.9']
    title = 'Move test sub-packages to Lib/test'
    updated_at = <Date 2021-11-16.14:13:17.853>
    user = 'https://github.com/voidspace'

    bugs.python.org fields:

    activity = <Date 2021-11-16.14:13:17.853>
    actor = 'erlendaasland'
    assignee = 'none'
    closed = False
    closed_date = None
    closer = None
    components = ['Tests']
    creation = <Date 2010-11-29.00:52:57.129>
    creator = 'michael.foord'
    dependencies = []
    files = ['29204', '29209', '29249', '29250', '36316', '36317']
    hgrepos = []
    issue_num = 10572
    keywords = ['patch', 'easy']
    message_count = 58.0
    messages = ['122751', '122815', '122817', '122818', '122820', '122828', '122830', '122838', '122841', '122847', '122852', '127032', '179583', '179587', '179588', '179589', '179596', '182809', '182822', '182913', '182926', '182952', '182954', '182982', '183074', '183078', '183087', '224186', '224299', '224342', '225079', '225083', '360661', '361240', '361325', '361401', '361446', '362090', '362101', '362844', '363106', '364232', '364233', '364248', '364312', '364357', '364358', '364359', '364448', '364827', '389357', '397580', '397649', '405031', '405351', '405422', '405423', '406404']
    nosy_count = 23.0
    nosy_names = ['barry', 'brett.cannon', 'theller', 'rhettinger', 'terry.reedy', 'ghaering', 'belopolsky', 'benjamin.peterson', 'tarek', 'gpolo', 'ned.deily', 'ezio.melotti', 'eric.araujo', 'r.david.murray', 'michael.foord', 'berker.peksag', 'zach.ware', 'serhiy.storchaka', 'gmwils', 'pablogsal', 'miss-islington', 'erlendaasland', 'Leonardofreua']
    pr_nums = ['18524', '18727', '24148', '29304', '29327']
    priority = 'normal'
    resolution = None
    stage = 'patch review'
    status = 'open'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue10572'
    versions = ['Python 3.9']

    Activity

    1. voidspace commented on Nov 29, 2010

      @voidspace
      ContributorAuthor

      Having tests in Lib/test instead of inside the package makes it easier to grep the unittest package without grepping the tests. The Windows installer has an "install without tests" option which is easier to honour if the tests aren't in the package.

      However, currently all packages that have test *packages* have the tests in the package rather than inside Lib/test. (There are no test packages inside Lib/test.)

      Examples: email, distutils, ctypes, importlib, json, lib2to3, sqlite3

      I also maintain an external port of unittest from Python 3. This is unittest2-py3k. Moving the tests would make it *slightly* harder to keep this in sync. I'm moving to maintaining this port as a set of patches rather than a separate branch. These patches can be applied automatically to unittest from py3k head. unittest2-py3k will be built automatically by a script, so it isn't a big deal.

    2. self-assigned this
      on Nov 29, 2010
    3. ezio-melotti commented on Nov 29, 2010

      @ezio-melotti
      Member

      3.1 should also be considered if the tests are moved. In theory this is not a bug fix so it shouldn't go in 3.1, but in practice it will make merging more difficult. This might not be a strong argument though, considering that 3.1 will accept only security fixes soon and only the few developers that work on unittest will be affected.

    4. voidspace commented on Nov 29, 2010

      @voidspace
      ContributorAuthor

      The same is true for 2.7 though, and that is getting bug fixes. svnmerge would no longer work (and to making the change would mean moving the tests in a point release).

    5. abalkin commented on Nov 29, 2010

      @abalkin
      Member

      +0, and I think we should hear from the maintainers of the affected packages first. For packages that are also externally maintained moving tests out may cause inconvenience to the maintainer.

    6. voidspace commented on Nov 29, 2010

      @voidspace
      ContributorAuthor

      That list of examples was non-exhaustive, there is also tkinter.

    7. bitdancer commented on Nov 29, 2010

      @bitdancer
      Member

      For the email package I would be in favor of moving the tests to Lib/test. I've always found it a bit inconvenient that they are in Lib/email. After hearing of Michael's intent with unittest, and given the evolution of email5 into email5.1, I am also considering the possibility of packaging email6 (when I get to it!) as a patch set against email5, which would make this change less of an issue for email6 development.

      The 2.7 sync issue is a concern, but there are certainly precedents for differing file layouts between 3.x and 2.7. I'm willing myself to deal with this for email.

      Barry may have a different opinion.

      All of that said, this is a general enough issue that it may be appropriate to raise it on python-dev. Even if exceptions are made for individual packages, it would be good to agree on a general "best practices" rule for this for the stdlib.

    8. warsaw commented on Nov 29, 2010

      @warsaw
      Member

      grepping the code without the tests doesn't seem that compelling a use case to me, given that grep and find both provide options to prune directories. I do think that moving the tests out of the email package will make it harder to maintain and distribute as a separate package. However, if RDM thinks the burden won't be too high, and the advantages of a split outweigh the disadvantages, then I defer to him. I would still make a case for distributing email6 as a package available on Cheeseshop though, otherwise it just won't get much independent use until it's in the stdlib.

    9. bitdancer commented on Nov 29, 2010

      @bitdancer
      Member

      Yes, a cheeseshop package is definitely part of the plan, I didn't mean to imply otherwise. It won't be hard to automate the packaging, and indeed I'll wind up doing that anyway even if the tests stay inside Lib/email.

      I will say that that I'm probably only +0.5 on this change...I like it from a consistency standpoint (heading toward all stdlib tests being in Lib/test) and it seems like it would make the job of packagers who desire a 'no tests' option easier. But things have been working fine as they are, which is why I'm not at a full +1 :).

    10. merwok commented on Nov 29, 2010

      @merwok
      Member

      For distutils tests, I’m ±0. I don’t see any major drawback nor any major benefit. Tarek will decide.

    11. rhettinger commented on Nov 29, 2010

      @rhettinger
      Contributor

      Of those, it makes the most sense to move the json tests to Lib/tests. Bob is not externally maintaining the 3.x version. It's all our now.

      Also, it looks like importlib is in a maintenance mode now.

      There is merit to keeping 2to3, ctypes, sqlite tests separate.

      Currently all of the documentation files are still under Doc so we should keep it that way and not move them under package directory trees.

    12. brettcannon commented on Nov 29, 2010

      @brettcannon
      Member

      I have no issue with moving importlib into Lib/test as long as I can still run the tests with python3 -m test.importlib. I actually only put the tests in importlib.tests because that was common practice amongst newer packages in the stdlib.

      And just to prevent some rumour from perpetuating, importlib is not in maintenance mode. In fact the API was heavily reworked in 3.2 and I plan on exposing more of the API publicly in 3.3 and hopefully to bootstrap as well. The only thing you could think is in maintenance mode is importlib's Chesseshop package, but that's just for 2.x compatibility and for Django's benefit.

    13. abalkin commented on Jan 25, 2011

      @abalkin
      Member

      Changing the title to reflect broader scope of this issue. Json tests were moved to Lib/test/json_tests in r86875.

    14. 74 remaining items

    15. vstinner commented on Jun 22, 2022

      @vstinner
      Member

      Lib/idlelib/idle_test/ is the last Lib/ sub-directory which contains tests which are not under Lib/test/. I wait for @terryjreedy's last word on my PR #94145 to see if we move IDLE tests, or if we leave tests there and just close the issue.

    16. erlend-aasland commented on Jul 20, 2022

      @erlend-aasland
      Contributor

      What's the status of the remaining test dirs? Can we close this?

    17. added 2 commits that reference this issue on Jul 20, 2022
    18. added a commit that references this issue on Jul 20, 2022
    19. added a commit that references this issue on Jul 20, 2022
    20. added a commit that references this issue on Jul 20, 2022
    21. brettcannon commented on Jul 20, 2022

      @brettcannon
      Member

      I think we may be as close as we're going to get due to Terry's request to leave IDLE's tests in place.

    22. terryjreedy commented on Jul 20, 2022

      @terryjreedy
      Member

      Thank you Brett. I opened #95069 for possibly moving IDLE tests someday (but not until after 3.11), in which I better explain the special issues I see.

    23. vstinner commented on Aug 3, 2022

      @vstinner
      Member

      Thanks everybody for helping on fixing this old issue ;-) Better late than never!

    24. moved this from Todo to Done in Contribution Queueon Feb 5, 2023
    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

      3.12only security fixeseasytestsTests in the Lib/test dirtype-featureA feature request or enhancement

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions