Skip to content
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

bpo-38488: Upgrade bundled versions of pip & setuptools #16782

Merged
merged 1 commit into from
May 27, 2020

Conversation

xavfernandez
Copy link
Contributor

@xavfernandez xavfernandez commented Oct 14, 2019

Following the release of pip 19.3.

It's unclear to me if a bpo ticket is needed ?

https://bugs.python.org/issue38488

@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@xavfernandez

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@tirkarthi
Copy link
Member

This would need a bpo and a news entry similar to https://bugs.python.org/issue35807 .

@xavfernandez xavfernandez changed the title Upgrade bundled versions of pip & setuptools bpo-38488: Upgrade bundled versions of pip & setuptools Oct 15, 2019
import pip._internal
return pip._internal.main(args)
import pip._internal.main
return pip._internal.main.main(args)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we OK to change this to use runpy? That way we'd basically be doing python -m pip, which is directly supported.

See https://github.com/pradyunsg/pip-cli/blob/master/src/_pip_cli.py#L75 for how we can do that. You can skip setting the env there, since that's for passing information that's not relevant here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't say that it's directly supported (as in, part of the public API) since running in the same process space is still not considered supported, but it would avoid any issues with changes to the location of the entrypoint function.

It may also be helpful to consider backporting that change to bugfix Python versions, which can help people that build and patch in new versions of pip (as mentioned in 09fd200).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this not simply run in a sub-process, then?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't use runpy (or a subprocess) here because of the path manipulation just above to import pip from the bundled wheel archives.

It's useful to think of ensurepip as being part of pip, as we're free to make whatever changes are needed to sync up when updating to new versions of pip.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://bugs.python.org/issue38662 is now fixed in master. You can rebased your PR on master.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@pradyunsg
Copy link
Member

/cc @dstufft @pfmoore

@xavfernandez xavfernandez force-pushed the update_bundled_wheels branch from 44071d4 to 821012e Compare October 18, 2019 09:18
chrahunt referenced this pull request in pypa/pip Oct 26, 2019
Moving content out of `__init__` is preferred in general because it
avoids conflicts with module names and unnecessary imports.
@encukou
Copy link
Member

encukou commented Dec 11, 2019

Also see this Discourse discussion: https://discuss.python.org/t/can-we-finally-add-a-minimal-api-to-pip/2833

@encukou
Copy link
Member

encukou commented Dec 12, 2019

The best (though still not supported) way to run pip in-process is with runpy, as mentioned in a new comment in pip: https://github.com/pypa/pip/pull/7471/files

Could you update the pull request to use that?
Note that it will exit() the current process, so it will need a documentation change and a what's new entry.

Please comment if you have any questions, or if you'd prefer to leave this to someone else.

@pradyunsg
Copy link
Member

A subprocess.run might be a more robust solution here.

@taleinat
Copy link
Contributor

A subprocess.run might be a more robust solution here.

As I mentioned in the inline comment, I wonder why this isn't run in a sub-process, and suggest doing so.

Regardless, that could be a separate issue. This simple update should likely go in.

@taleinat
Copy link
Contributor

@xavfernandez, have you any intention to continue working on this?

@pradyunsg
Copy link
Member

Sounds fair to me -- I filed a bpo issue for this a while back -- maybe someone/me can find it and link to it from here.

None of my concerns here are blocking this version update, which should definitely go in.

@tirkarthi
Copy link
Member

@pradyunsg Is it this https://bugs.python.org/issue38662?

@xavfernandez
Copy link
Contributor Author

@xavfernandez, have you any intention to continue working on this?

Yes, however it's unclear what needs to be done in this PR ?
Should I switch to runpy and follow encukou suggestion ?
Or simply launch a subprocess running python -m pip ?

@pradyunsg
Copy link
Member

pradyunsg commented Dec 12, 2019

@tirkarthi Yes, indeed. Many thanks for finding that. :)

@xavfernandez IMO nothing else is needed here -- we can tackle those in a follow up.

/cc @ncoghlan @dstufft @pfmoore in case one of them wants to review + click merge here. :)

@taleinat
Copy link
Contributor

taleinat commented Dec 12, 2019

By now the latest versions of setuptools and pip have moved along:

So we should bump those and then IMO this would be ready to go.

EDIT: P.S. Apologies for the delay so far, I'll make sure this moves along quickly now.

@xavfernandez xavfernandez force-pushed the update_bundled_wheels branch from 7b22480 to 75a8678 Compare March 27, 2020 15:11
@xavfernandez xavfernandez force-pushed the update_bundled_wheels branch from 75a8678 to f77f057 Compare April 28, 2020 20:36
@xavfernandez xavfernandez force-pushed the update_bundled_wheels branch from f77f057 to 9297a25 Compare April 28, 2020 20:38
@csabella csabella requested review from ncoghlan, dstufft and pfmoore May 23, 2020 17:51
Copy link
Contributor

@ncoghlan ncoghlan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry about the delay, I suspect this was a case of all of us assuming one of the others would approve & merge it.

@ncoghlan ncoghlan merged commit feb0846 into python:master May 27, 2020
@bedevere-bot
Copy link

@ncoghlan: Please replace # with GH- in the commit message next time. Thanks!

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot s390x Fedora Clang Installed 3.x has failed when building commit feb0846.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/505/builds/570) and take a look at the build logs.
  4. Check if the failure is related to this commit (feb0846) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/505/builds/570

Summary of the results of the build (if available):

== Tests result: SUCCESS ==

406 tests OK.

19 tests skipped:
test_asdl_parser test_check_c_globals test_clinic test_devpoll
test_gdb test_ioctl test_kqueue test_msilib test_nis
test_ossaudiodev test_readline test_startfile test_tix test_tk
test_ttk_guionly test_winconsoleio test_winreg test_winsound
test_zipfile64

Total duration: 4 min 20 sec

Click to see traceback logs
remote: Enumerating objects: 16, done.        
remote: Counting objects:   6% (1/16)        
remote: Counting objects:  12% (2/16)        
remote: Counting objects:  18% (3/16)        
remote: Counting objects:  25% (4/16)        
remote: Counting objects:  31% (5/16)        
remote: Counting objects:  37% (6/16)        
remote: Counting objects:  43% (7/16)        
remote: Counting objects:  50% (8/16)        
remote: Counting objects:  56% (9/16)        
remote: Counting objects:  62% (10/16)        
remote: Counting objects:  68% (11/16)        
remote: Counting objects:  75% (12/16)        
remote: Counting objects:  81% (13/16)        
remote: Counting objects:  87% (14/16)        
remote: Counting objects:  93% (15/16)        
remote: Counting objects: 100% (16/16)        
remote: Counting objects: 100% (16/16), done.        
remote: Compressing objects:  10% (1/10)        
remote: Compressing objects:  20% (2/10)        
remote: Compressing objects:  30% (3/10)        
remote: Compressing objects:  40% (4/10)        
remote: Compressing objects:  50% (5/10)        
remote: Compressing objects:  60% (6/10)        
remote: Compressing objects:  70% (7/10)        
remote: Compressing objects:  80% (8/10)        
remote: Compressing objects:  90% (9/10)        
remote: Compressing objects: 100% (10/10)        
remote: Compressing objects: 100% (10/10), done.        
remote: Total 20 (delta 7), reused 6 (delta 6), pack-reused 4        
From https://github.com/python/cpython
 * branch                  master     -> FETCH_HEAD
Reset branch 'master'

Python/pytime.c:154:10: warning: implicit conversion from 'long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-int-float-conversion]
    if (!_Py_InIntegralTypeRange(time_t, intpart)) {
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./Include/pymath.h:228:82: note: expanded from macro '_Py_InIntegralTypeRange'
#define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v && v <= _Py_IntegralTypeMax(type))
                                                                              ~~ ^~~~~~~~~~~~~~~~~~~~~~~~~
./Include/pymath.h:221:124: note: expanded from macro '_Py_IntegralTypeMax'
#define _Py_IntegralTypeMax(type) ((_Py_IntegralTypeSigned(type)) ? (((((type)1 << (sizeof(type)*CHAR_BIT - 2)) - 1) << 1) + 1) : ~(type)0)
                                                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
Python/pytime.c:207:14: warning: implicit conversion from 'long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-int-float-conversion]
        if (!_Py_InIntegralTypeRange(time_t, intpart)) {
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./Include/pymath.h:228:82: note: expanded from macro '_Py_InIntegralTypeRange'
#define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v && v <= _Py_IntegralTypeMax(type))
                                                                              ~~ ^~~~~~~~~~~~~~~~~~~~~~~~~
./Include/pymath.h:221:124: note: expanded from macro '_Py_IntegralTypeMax'
#define _Py_IntegralTypeMax(type) ((_Py_IntegralTypeSigned(type)) ? (((((type)1 << (sizeof(type)*CHAR_BIT - 2)) - 1) << 1) + 1) : ~(type)0)
                                                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
Python/pytime.c:392:10: warning: implicit conversion from 'long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-int-float-conversion]
    if (!_Py_InIntegralTypeRange(_PyTime_t, d)) {
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./Include/pymath.h:228:82: note: expanded from macro '_Py_InIntegralTypeRange'
#define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v && v <= _Py_IntegralTypeMax(type))
                                                                              ~~ ^~~~~~~~~~~~~~~~~~~~~~~~~
./Include/pymath.h:221:124: note: expanded from macro '_Py_IntegralTypeMax'
#define _Py_IntegralTypeMax(type) ((_Py_IntegralTypeSigned(type)) ? (((((type)1 << (sizeof(type)*CHAR_BIT - 2)) - 1) << 1) + 1) : ~(type)0)
                                                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
3 warnings generated.
./Modules/timemodule.c:116:13: warning: code will never be executed [-Wunreachable-code]
            PyErr_SetString(PyExc_OverflowError,
            ^~~~~~~~~~~~~~~
./Modules/_threadmodule.c:1587:19: warning: implicit conversion from '_PyTime_t' (aka 'long') to 'double' changes value from 9223372036854775 to 9223372036854776 [-Wimplicit-int-float-conversion]
    timeout_max = (_PyTime_t)PY_TIMEOUT_MAX * 1e-6;
                  ^~~~~~~~~~~~~~~~~~~~~~~~~ ~
1 warning generated.
1 warning generated.
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/Modules/_decimal/libmpdec/mpdecimal.c:7940:25: warning: implicit conversion from 'unsigned long' to 'double' changes value from 18446744073709551614 to 18446744073709551616 [-Wimplicit-int-float-conversion]
    return (x > SIZE_MAX-1) ? SIZE_MAX : (size_t)x + 1;
              ~ ~~~~~~~~^~
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/Modules/_decimal/libmpdec/mpdecimal.c:7959:18: warning: implicit conversion from 'long' to 'double' changes value from 105263157894736842 to 105263157894736848 [-Wimplicit-int-float-conversion]
    return (x >= MPD_MAXIMPORT) ? MPD_SSIZE_MAX : (mpd_ssize_t)x + 1;
              ~~ ^~~~~~~~~~~~~
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/Modules/_decimal/libmpdec/mpdecimal.h:175:23: note: expanded from macro 'MPD_MAXIMPORT'
#define MPD_MAXIMPORT 105263157894736842L /* ceil((2*MPD_MAX_PREC)/MPD_RDIGITS) */
                      ^~~~~~~~~~~~~~~~~~~
2 warnings generated.

  WARNING: The script easy_install-3.10 is installed in '/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/target/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The scripts pip3 and pip3.10 are installed in '/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/target/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.

chmod: target/lib/python3.10/site-packages/setuptools-46.1.3.dist-info/RECORD: new permissions are r-xrw-rwx, not r-xr--r-x
chmod: target/lib/python3.10/site-packages/setuptools-46.1.3.dist-info/INSTALLER: new permissions are r-xrw-rwx, not r-xr--r-x
chmod: target/lib/python3.10/site-packages/pip-20.1.dist-info/RECORD: new permissions are r-xrw-rwx, not r-xr--r-x
chmod: target/lib/python3.10/site-packages/pip-20.1.dist-info/INSTALLER: new permissions are r-xrw-rwx, not r-xr--r-x

test_check_c_globals skipped -- c-analyzer directory could not be found
test_gdb skipped -- Couldn't find gdb on the path
test_devpoll skipped -- test works only on Solaris OS family
test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run
test_startfile skipped -- object <module 'os' from '/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/target/lib/python3.10/os.py'> has no attribute 'startfile'
test_kqueue skipped -- test works only on BSD
test_asdl_parser skipped -- test irrelevant for an installed Python
test_msilib skipped -- No module named 'msilib'
test_nis skipped -- No module named 'nis'
test_tix skipped -- Tk unavailable due to TclError: no display name and no $DISPLAY environment variab [...]
test_winreg skipped -- No module named 'winreg'
test_clinic skipped -- clinic directory could not be found
test_winsound skipped -- No module named 'winsound'
test_ttk_guionly skipped -- Tk unavailable due to TclError: no display name and no $DISPLAY environment variab [...]
test_readline skipped -- No module named 'readline'
test_tk skipped -- Tk unavailable due to TclError: no display name and no $DISPLAY environment variab [...]
test_winconsoleio skipped -- test only relevant on win32
test_flock (__main__.FNTLEINTRTest) ... ok
test_lockf (__main__.FNTLEINTRTest) ... ok
test_read (__main__.OSEINTRTest) ... ok
test_wait (__main__.OSEINTRTest) ... ok
test_wait3 (__main__.OSEINTRTest) ... ok
test_wait4 (__main__.OSEINTRTest) ... ok
test_waitpid (__main__.OSEINTRTest) ... ok
test_write (__main__.OSEINTRTest) ... ok
test_devpoll (__main__.SelectEINTRTest) ... skipped 'need select.devpoll'
test_epoll (__main__.SelectEINTRTest) ... ok
test_kqueue (__main__.SelectEINTRTest) ... skipped 'need select.kqueue'
test_poll (__main__.SelectEINTRTest) ... ok
test_select (__main__.SelectEINTRTest) ... ok
test_sigtimedwait (__main__.SignalEINTRTest) ... ok
test_sigwaitinfo (__main__.SignalEINTRTest) ... ok
test_accept (__main__.SocketEINTRTest) ... ok
test_open (__main__.SocketEINTRTest) ... ok
test_os_open (__main__.SocketEINTRTest) ... ok
test_recv (__main__.SocketEINTRTest) ... ok
test_recvmsg (__main__.SocketEINTRTest) ... ok
test_send (__main__.SocketEINTRTest) ... ok
test_sendall (__main__.SocketEINTRTest) ... ok
test_sendmsg (__main__.SocketEINTRTest) ... ok
test_sleep (__main__.TimeEINTRTest) ... ok

----------------------------------------------------------------------
Ran 24 tests in 6.277s

OK (skipped=2)
test_ioctl skipped -- Unable to open /dev/tty
test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp'

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot x86 Gentoo Installed with X 3.x has failed when building commit feb0846.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/128/builds/953) and take a look at the build logs.
  4. Check if the failure is related to this commit (feb0846) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/128/builds/953

Summary of the results of the build (if available):

== Tests result: SUCCESS ==

412 tests OK.

13 tests skipped:
test_asdl_parser test_check_c_globals test_clinic test_devpoll
test_gdb test_ioctl test_kqueue test_msilib test_startfile
test_winconsoleio test_winreg test_winsound test_zipfile64

Total duration: 36 min 55 sec

Click to see traceback logs
remote: Enumerating objects: 9, done.        
remote: Counting objects:  11% (1/9)        
remote: Counting objects:  22% (2/9)        
remote: Counting objects:  33% (3/9)        
remote: Counting objects:  44% (4/9)        
remote: Counting objects:  55% (5/9)        
remote: Counting objects:  66% (6/9)        
remote: Counting objects:  77% (7/9)        
remote: Counting objects:  88% (8/9)        
remote: Counting objects: 100% (9/9)        
remote: Counting objects: 100% (9/9), done.        
remote: Compressing objects:  20% (1/5)        
remote: Compressing objects:  40% (2/5)        
remote: Compressing objects:  60% (3/5)        
remote: Compressing objects:  80% (4/5)        
remote: Compressing objects: 100% (5/5)        
remote: Compressing objects: 100% (5/5), done.        
remote: Total 13 (delta 4), reused 5 (delta 4), pack-reused 4        
From https://github.com/python/cpython
 * branch                  master     -> FETCH_HEAD
Reset branch 'master'

Python/initconfig.c: In function ‘init_dump_ascii_wstr’:
Python/initconfig.c:2646:34: warning: format ‘%lc’ expects argument of type ‘wint_t’, but argument 2 has type ‘wchar_t’ {aka ‘long int’} [-Wformat=]
 2646 |             PySys_WriteStderr("%lc", ch);
      |                                ~~^   ~~
      |                                  |   |
      |                                  |   wchar_t {aka long int}
      |                                  unsigned int
      |                                %ld
Python/initconfig.c:2649:38: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘wchar_t’ {aka ‘long int’} [-Wformat=]
 2649 |             PySys_WriteStderr("\\x%02x", ch);
      |                                   ~~~^   ~~
      |                                      |   |
      |                                      |   wchar_t {aka long int}
      |                                      unsigned int
      |                                   %02lx
Python/initconfig.c:2653:38: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘wchar_t’ {aka ‘long int’} [-Wformat=]
 2653 |             PySys_WriteStderr("\\U%08x", ch);
      |                                   ~~~^   ~~
      |                                      |   |
      |                                      |   wchar_t {aka long int}
      |                                      unsigned int
      |                                   %08lx
Python/initconfig.c:2657:38: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘wchar_t’ {aka ‘long int’} [-Wformat=]
 2657 |             PySys_WriteStderr("\\u%04x", ch);
      |                                   ~~~^   ~~
      |                                      |   |
      |                                      |   wchar_t {aka long int}
      |                                      unsigned int
      |                                   %04lx
/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/Modules/_zoneinfo.c: In function ‘load_data’:
/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/Modules/_zoneinfo.c:911:30: warning: comparison of integer expressions of different signedness: ‘Py_ssize_t’ {aka ‘int’} and ‘unsigned int’ [-Wsign-compare]
  911 |     for (Py_ssize_t i = 0; i < self->num_transitions; ++i) {
      |                              ^
/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/Modules/_zoneinfo.c:949:30: warning: comparison of integer expressions of different signedness: ‘Py_ssize_t’ {aka ‘int’} and ‘unsigned int’ [-Wsign-compare]
  949 |     for (Py_ssize_t i = 0; i < self->num_ttinfos; ++i) {
      |                              ^

  WARNING: The script easy_install-3.10 is installed in '/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  WARNING: The scripts pip3 and pip3.10 are installed in '/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.

chmod: target/lib/python3.10/site-packages/pip-20.1.dist-info/RECORD: new permissions are r-xrw-rwx, not r-xr--r-x
chmod: target/lib/python3.10/site-packages/pip-20.1.dist-info/INSTALLER: new permissions are r-xrw-rwx, not r-xr--r-x
chmod: target/lib/python3.10/site-packages/setuptools-46.1.3.dist-info/RECORD: new permissions are r-xrw-rwx, not r-xr--r-x
chmod: target/lib/python3.10/site-packages/setuptools-46.1.3.dist-info/INSTALLER: new permissions are r-xrw-rwx, not r-xr--r-x

@stratakis
Copy link
Contributor

Various buildbots which run the tests with an installed python, fail with:

chmod: target/lib/python3.10/site-packages/pip-20.1.dist-info/RECORD: new permissions are r-xrw-rwx, not r-xr--r-x
chmod: target/lib/python3.10/site-packages/pip-20.1.dist-info/INSTALLER: new permissions are r-xrw-rwx, not r-xr--r-x
chmod: target/lib/python3.10/site-packages/setuptools-46.1.3.dist-info/RECORD: new permissions are r-xrw-rwx, not r-xr--r-x
chmod: target/lib/python3.10/site-packages/setuptools-46.1.3.dist-info/INSTALLER: new permissions are r-xrw-rwx, not r-xr--r-x

@vstinner
Copy link
Member

Various buildbots which run the tests with an installed python, fail with: (...)

It's the "chmod" step which fails. I guess that only "Install" buildbot workers are affected. I failed to reproduce the issue with commands:

./configure --prefix $PWD/target --with-pydebug
make && make install
chmod -R -w target/

I get these permissions:

$ ls -l target/lib/python3.10/site-packages/setuptools-46.1.3.dist-info/RECORD
-r--r--r--. 1 vstinner vstinner 14560 28 mai   03:40 target/lib/python3.10/site-packages/setuptools-46.1.3.dist-info/RECORD

@vstinner
Copy link
Member

I reverted the change: see https://bugs.python.org/issue38488

@xavfernandez
Copy link
Contributor Author

The permission issue is likely due to pypa/pip#8164 that was fixed in 20.1.1.
Sorry I did not keep this PR up-to-date with the latest pip, #20491 should hopefully fix this.

@xavfernandez xavfernandez deleted the update_bundled_wheels branch May 28, 2020 14:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.