stderr duplication failed in console scripts

[pierreluctg]

Description

I use a console_scripts entry point with a test function. If I do pip install . or use setup.py to make a binary dist then install it, under some shell like Git Bash, running the created test-script.exe. stdin, stdout and stderr should all be set to a TextIOWrapper however, stderr is set to None.

The stderr handle is apparently not correctly set.

This is probably related to #10444 and the fix introduced in Distlib 0.3.4 for a similar issue.

Expected behavior

$ test-script.exe
stdin=<_io.TextIOWrapper name='<stdin>' mode='r' encoding='cp1252'>
stdout=<_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp1252'>
stderr=<_io.TextIOWrapper name='<stderr>' mode='w' encoding='cp1252'>

pip version

22.0

Python version

Python 3.7

OS

Windows

How to Reproduce

# setup.py
from setuptools import setup

setup(
    name="test",
    packages=["testing"],
    entry_points={
        "console_scripts": [
            "test-script=testing:main"
        ]
    }
)

# testing/__init__.py
import sys


def main():
    print(f"stdin={sys.stdin}")
    print(f"stdout={sys.stdout}")
    print(f"stderr={sys.stderr}")

Output

# With pip 21.*
$ test-script.exe
stdin=<_io.TextIOWrapper name='<stdin>' mode='r' encoding='cp1252'>
stdout=<_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp1252'>
stderr=<_io.TextIOWrapper name='<stderr>' mode='w' encoding='cp1252'>

# With pip 22.0, 22.0.1 and 22.0.2 
$ test-script.exe
stdin=<_io.TextIOWrapper name='<stdin>' mode='r' encoding='cp1252'>
stdout=<_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp1252'>
stderr=None

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pradyunsg]

/cc @vsajip, since they're the expert here. :)

[pradyunsg]

x-ref #10874, which also seems like something that's related to the Windows launchers.

[pierreluctg]

The following Java code calling test-script.exe (the console script) is also producing the issue:

package com.example.testScript;

import java.io.IOException;

public class TestScript {
    public static void main(String[] args) throws IOException, InterruptedException {
        String cmd = "test-script.exe";
        ProcessBuilder pb = new ProcessBuilder().command(cmd);

        // This is apparently exposing the issue
        pb.redirectErrorStream(true);

        Process iostat = pb.inheritIO().start();
        int exitCode = iostat.waitFor();
        System.out.println("exitCode = " + exitCode);
    }
}

[pierreluctg]

@vsajip can you please have a look at this distlib regression?

Switching the distlib binaries back to 0.3.3 (from pip 21.x) or moving back to pip 21.x is not showing the issue.

In the affected effected environment this is a major issue.

thank you

[carlkl]

Right now I can only recommend to install an older pip version on Windows: python -m pip install -U pip==21.3.1
After that all packages with broken launchers also should be reinstalled.

[vsajip]

@pierreluctg I'm aware of this issue, but I probably won't have the bandwidth to spend much (if any) time on it until the last week of March 2022, due to other commitments 😞

[pierreluctg]

Thank you @vsajip for the update. Is there any additional information that you need from us in the meantime to help you fix the issue when you will have free time?

[carlkl]

Right now my solution is to install an older pip version on Windows: python -m pip install -U pip==21.3.1. After that all packages with faulty launchers should also be reinstalled. I've seen issues with meson as well as with tqdm.

[pradyunsg]

Is this bad enough to justify a bug fix release?

[shireenrao]

I have started running my console scripts with Python to get around this for now

$ python -m pytest

[vsajip]

Is there any additional information that you need from us in the meantime to help you fix the issue when you will have free time?

Does the problem occur for GUI scripts as well as console scripts? (Might be harder to ascertain, as there's no console to display diagnostic output). Other than that, no other things I can think of.

[aminya]

Right now my solution is to install an older pip version on Windows: python -m pip install -U pip==21.3.1. After that all packages with faulty launchers should also be reinstalled. I've seen issues with meson as well as with tqdm.

@carlkl

For meson as an example, it is enough to run the following? or should it be specifically installed via the pip executable?

python -m pip install -U pip==21.3.1
python -m pip install meson

[carlkl]

@aminya,

For meson as an example, it is enough to run the following? or should it be specifically installed via the pip executable?
python -m pip install -U pip==21.3.1
python -m pip install meson

I reinstalled meson in excact that way.

[pfmoore]

Is this bad enough to justify a bug fix release?

It doesn't seem to happen all the time. The following reproducer builds a simple console executable, and when I run that it works fine (shows stderr as a file, not as None, and writes output to stderr).

So I think someone needs to be more precise about how this issue gets triggered, before we can assess the severity of the problem. (On the other hand, if pip install meson is installing a broken application, that's fairly severe for meson users, so maybe that's enough on its own? How broken is meson as a result of this bug? Does it not work at all, or is it only particular functionality that's affected?)

py -m venv .venv
.venv/scripts/python -m pip install -U pip setuptools wheel
mkdir test_bug
set-content test_bug/test_bug.py -encoding UTF8 @"
import sys
def main():
    print(repr(sys.stdin))
    print(repr(sys.stdout))
    print(repr(sys.stderr))
    print('Writing to stdout')
    print('Writing to stderr', file=sys.stderr)
"@
set-content test_bug/setup.py -encoding UTF8 @"
from setuptools import setup
setup(
    name='test_bug',
    version='1.0',
    py_modules=['test_bug'],
    entry_points = {
        'console_scripts': ['test_bug=test_bug:main'],
    },
)
"@
.venv/scripts/pip install ./test_bug
.venv/scripts/test_bug.exe

[carlkl]

@pfmoore, I don't know how more more precise, please take a look at: #10444 (comment). Other projects now have problems with pip 22, not only meson. To be even more precise: The problem is due to the change to distlib-0.34.

On windows you have to use the meson launcher, as pip -m meson dosn't work. If meson was install with pip 22 meson doesn't work anymore due to this issue.

[pfmoore]

@carlkl I understand what the problem is, and I understand what we'd need to do to fix it (revert to an older distlib, or wait for a distlib fix). What I don't know is how many people are affected, nor do I know whether this issue is more disruptive than the issue that the distlib upgrade fixed, or whether it will be more disruptive than the cost of making a bugfix release.

The comment you linked to says it is a "severe" bug. It's not severe for me, I've never seen it happen. So if you can be more precise about what circumstances cause it to occur, that would make it easier to assess the severity in a way that doesn't just boil down to "it doesn't happen for me" vs "it happens for a program someone else uses a lot". You also say "Now sys.stderr is None if you start launchers created by pip 22". My reproducer above demonstrates that this isn't always true. So the question is how often is that the case, and under what circumstances. I can't tell, because as yet I haven't ever had it happen for me.

🤷 I'm not really that bothered. Ultimately someone needs to make the case that this is important enough for us to produce a bugfix release with a reverted distlib. I'm only trying to help people make that case - if they don't, then this will likely just wait for a fix in distlib, and the next pip release.

[carlkl]

main issue: #10444

Here is a list of affected projects I'm aware of:

• mesonlib: Fix Popen_safe_legacy() stderr assumption mesonbuild/meson#9918
• Built application executables broken since distlib 0.3.4 takluyver/pynsist#243 is somehow related
• also tqdm needs sys.stderr during installation
• and another project somewhere I forgot to bookmark,

As I understand, it will happen if (and only if):

• you installed pip 22 first
• you install meson or any other project (which depends on sys.stderr) afterwards
• you use the binary launcher instead oy python -m whatever

IMHO it is a severe problem that will most likely hit other project sooner or later. In case it pops up you have absolutely no clue what happens. It took me hours to come to that conclusion with pip 22 and distutils.

[pfmoore]

• [BUG] stderr duplication failed #10444 is about GUI script wrappers, isn't it?
• A brief skim of the nsist issue also seems to be about GUI executables.
• I don't get anything failing when I install tqdm, or run the tqdm executable.

As I understand, it will happen if (and only if):

• you installed pip 22 first - I did that
• you install meson or any other project (which depends on sys.stderr) afterwards - I did that, assuming my test project counts
• you use the binary launcher instead oy python -m whatever - I did that

As I say, I can't reproduce this.

If it's only about GUI executables, my view is that it's (a) not demonstrably worse than reverting, as I believe the distlib change was to fix some aspect of how GUI scripts were handled, and (b) not major, demonstrated by the fact that the original distlib issue had gone for so long without being reported.

The meson case worries me more, as it seems to be related to a console script. But until someone can provide a reproducer which doesn't involve meson, I remain unconvinced it's a general issue.

Note: I'm not the RM for 22.0. If @pradyunsg decides to do a bugfix release, that's fine. I'm mostly interested here as I want to improve the process whereby we gather information about post-release issues, and in particular establish a principle that we should be looking for more objective measures of the impact rather than just reacting to generalised "it's broken" messages.

[eli-schwartz]

The Meson issue as reported by one of our users apparently only manifests in CI, not on local dev machines, and only happens when meson.exe's symbolextractor internal command is launched by ninja, and it works okay when launched by hand.

Ninja does do some playing around with file descriptors, because stdout/stderr get buffered (failing isatty() checks) in order to print all output when ninja finds best, particularly to avoid mixing output from multiple build rules running simultaneously in a parallel build.

[julie777]

• [BUG] stderr duplication failed #10444 is about GUI script wrappers, isn't it?

It is definitely not just about GUI script wrappers.
I used pipx to install pre-commit which failed with a return code and no output because it is trying to write to stderr.

[pradyunsg]

So the old version of distlib broke certain GUI use cases by making error dialog boxes pop up.

The new version of distlib broke other -- CLI this time -- use cases by making them error out silently.

This is good context, thanks for noting this here @eli-schwartz!

I think having a visible (albeit cryptic) error that users can discover is better than a silent error that they can't. Further, CLI entry points are a lot more common than GUI entry points and I'm pretty sure the right thing to do here is to downgrade distlib to 0.3.3 until @vsajip is able able to fix this issue in distlib.

I'll cut a bugfix for this.

[vsajip]

Hmmm. See detailed analysis of this and related problems by Michael Bikovitsky here.

[pradyunsg]

I've reopened this, for tracking the fix being released on distlib's end (since we can't update our vendored copy until distlib fixes the underlying issue).

[vsajip]

There have been two distlib releases since - 0.3.5 on 2022-07-14 and 0.3.6 on 2022-08-26.

[vsajip]

Is this issue still extant, or can it be closed?

[cbrnr]

It works for me (just tried with pip 22.3.1)!

[carlkl]

No problems on Windows so far.
Tested environment: local development on Windows10 Python-3.8 - 3.11 32-bit, 64-bit

[pradyunsg]

Thanks @vsajip for the fixes! ^>^