Skip to content

Doctest in CI uses python binary built from master causing DeprecationWarnings #79290

Closed

Description

@tirkarthi
BPO 35109
Nosy @matrixise, @JulienPalard, @tirkarthi

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 = <Date 2018-11-03.15:16:40.509>
created_at = <Date 2018-10-30.08:34:25.260>
labels = ['build', '3.8', 'docs']
title = 'Doctest in CI uses python binary built from master causing DeprecationWarnings'
updated_at = <Date 2018-11-03.15:16:40.507>
user = 'https://github.com/tirkarthi'

bugs.python.org fields:

activity = <Date 2018-11-03.15:16:40.507>
actor = 'mdk'
assignee = 'docs@python'
closed = True
closed_date = <Date 2018-11-03.15:16:40.509>
closer = 'mdk'
components = ['Build', 'Documentation']
creation = <Date 2018-10-30.08:34:25.260>
creator = 'xtreak'
dependencies = []
files = []
hgrepos = []
issue_num = 35109
keywords = []
message_count = 8.0
messages = ['328886', '328955', '328956', '328957', '328958', '328959', '329195', '329200']
nosy_count = 4.0
nosy_names = ['docs@python', 'matrixise', 'mdk', 'xtreak']
pr_nums = []
priority = 'normal'
resolution = 'third party'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue35109'
versions = ['Python 3.8']

Activity

  1. tirkarthi commented on Oct 30, 2018

    @tirkarthi
    MemberAuthor

    Currently we run doctest in CI and we use the environment variable PYTHON to get the path of python binary to be used for virtualenv creation. We set PYTHON=../python in .travis.yml at [0] before running tests thus this causes the CI to use development version of the binary. Some of the modules used for doctest have incompatible changes related to importing from collections. The DeprecationWarning related code will be removed in 3.8 thus it will cause the doctest to fail while using the modules in CI. Since I have enabled -W in bpo-34081 they are visible now.

    I propose using stable version of Python like python 3.7 so that when we remove collections import related code in master the doctest doesn't fail on Travis. There are respective PRs for this warnings in the repo but using stable version will fix this. We don't need to test the modules against the master branch of Python for doctest which is currently doing.

    Sample warning : https://travis-ci.org/python/cpython/jobs/448195459#L2603

    /home/travis/build/python/cpython/Doc/venv/lib/python3.8/site-packages/babel/localedata.py:17: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
    from collections import MutableMapping

    On local machine the .travis.yml is not executed thus it uses PYTHON=python3 in Doc/Makefile and thus this not a problem locally building the docs that uses a stable version of Python.

    Adding @mdk for feedback on this.

    [0] https://github.com/python/cpython/blob/master/.travis.yml#L164

  2. added
    buildThe build process and cross-build
    docsDocumentation in the Doc dir
    on Oct 30, 2018
  3. JulienPalard commented on Oct 30, 2018

    @JulienPalard
    Member

    I propose using stable version of Python like python 3.7

    If we do so, we won't be able to write doctest about new features (existing in 3.8, not existing in 3.7), which is worse than having warnings.

    I think the right move is to do some PR on remote projects (like babel) to fix the warning, future-proofing them from having a real issue in 3.8.

  4. tirkarthi commented on Oct 30, 2018

    @tirkarthi
    MemberAuthor

    I have an open PR for babel python-babel/babel#608 . The problem is merging them and cutting a new release depends on the maintainers availability. Once it's fixed we have to make sure dependencies of babel like sphinx use the latest version and also make a release if needed. I agree it has to be fixed on those projects but coordinating release across various projects depends on the maintainers availability and shouldn't end up as a blocker for CPython's development here and in future with these type of deprecation warnings. I suggested using a stable version because when ran locally make venv for doctest uses python3 as binary name and on CI it uses python built from master branch that might cause confusion. Also it's not necessarily CPython's responsibility to make sure all our external projects work well on development branch.

    We can keep this as an open issue while the warnings are fixed in the projects and also use this for reference when the collections import related code has to be removed.

  5. tirkarthi commented on Oct 30, 2018

    @tirkarthi
    MemberAuthor

    If we do so, we won't be able to write doctest about new features (existing in 3.8, not existing in 3.7), which is worse than having warnings.

    I agree with the same. Maybe I am running doctest wrong locally? I use make venv and make doctest. Sorry for the confusion on this.

  6. JulienPalard commented on Oct 30, 2018

    @JulienPalard
    Member

    Maybe I am running doctest wrong locally?

    Dunno. IIRC we had problems running doctest with a Python 3.7 on the 3.8 branch, which make sense.

    Anyway, if it works today, the first developper writing doctest about a 3.8 feature will cause a doctest failure so no we can't use 3.7 to test 3.8.

  7. tirkarthi commented on Oct 30, 2018

    @tirkarthi
    MemberAuthor

    Anyway, if it works today, the first developper writing doctest about a 3.8 feature will cause a doctest failure so no we can't use 3.7 to test 3.8.

    Agreed that we need to run on the master branch binary for 3.8 only features like PEP-572 which is a language level change. Sorry, I forgot about that scenario. I guess it's then the right way to fix the dependencies upstream so that they work properly on development branch going forward.

  8. matrixise commented on Nov 3, 2018

    @matrixise
    Member

    I think we could close this issue because the DeprecationWarnings are not related to Python itself but to the dependencies.

    We could open an issue about the DeprecationWarnings and the dependency like python-babel (thanks for the issue).

    @mdk? Can we close this issue?

  9. JulienPalard commented on Nov 3, 2018

    @JulienPalard
    Member

    Yes we can close it. Also -W from sphinx-build won't cause errors from those warnings.

    Yes we'll probably suffer a bit if someone push the final step of a deprecation if one of our build dependencies is still using it.

  10. transferred this issue fromon Apr 10, 2022
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.8 (EOL)end of lifebuildThe build process and cross-builddocsDocumentation in the Doc dir

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions