#627 allow for the -I option in the Python interpreter wrapper

[janwijbrand]

See issue #627.

[gotcha]

I am a bit uneasy with the fact that the option is accepted but silently swallowed. If ever anyone actually needs its normal effect, it will be hard to debug.

Would there be a way to advertise the flag is accepted but swallowed that would support your VSCode use case ?

[janwijbrand]

I see your point. I don't have a very good answer, but: VSCode cannot really know it is not calling a "real" interpreter, so I see how it expects the -I to be accepted.

-I indicates "I want an isolated python environment" that the wrapper actually sort of already provides - that was the line of reasoning I used for thinking this PR could be an OK solution.

Perhaps we could warn the user when they start the python wrapper in "interactive" mode and did pass in -I that the option is ignored? We can also add a comment in the wrapper about the -I being ignored, would that help?

Alternatively, we actually implement the "correct" -I behaviour. That seems overkill, but would provide the least surprise to the developer? Note that the wrapper script doesn't provide any hint on what options are acceptable - there is no -h or --help support for example. To know which options are acceptable one needs to read the wrapper anyway.

There's a fair chance we will be playing catch up: as soon as VSCode sees a good reason to pass another option native to the "normal" Python interpreter, we're back at square one.

[gotcha]

I do agree that implementing the correct behaviour is overkill.
I see your point about the lack of help and thus the need to read the script.
Nevertheless, it could be easy to miss the silent swallow so I think that adding a comment does make sense.

Any chance to have VSCode provide some configuration to avoid the issue ?

[gotcha]

There's a fair chance we will be playing catch up: as soon as VSCode sees a good reason to pass another option native to the "normal" Python interpreter, we're back at square one.

Unfortunately yup.

[janwijbrand]

I have no clear idea why https://github.com/buildout/buildout/actions/runs/4352805641/jobs/7670723752 is failing now. I can't really see a relation to my change. Anyone an idea of an approach to tackle this?

[janwijbrand]

Nevertheless, it could be easy to miss the silent swallow so I think that adding a comment does make sense.

I'll add a comment.

Any chance to have VSCode provide some configuration to avoid the issue ?

I don't see how to make that into a sensible request to the extension developer/maintainer. In a way, buildout is the odd one out here I'm afraid.

[gotcha]

@janwijbrand I used to refer to issues on websites, but they do eventually disappear. Would you mind explaining about VSCode need here ?

[gotcha]

I have no clear idea why https://github.com/buildout/buildout/actions/runs/4352805641/jobs/7670723752 is failing now. I can't really see a relation to my change. Anyone an idea of an approach to tackle this?

Current testing setup always uses last setuptools which changes far too often, resulting in broken doctests.
I need to change the GHA especially since I have added the possibility to specify setuptools and pip versions used by dev.py through env vars.

[janwijbrand]

Done

[gotcha]

I see you did not add a test (which I am fine with). I guess you are also fine with the low risk that someone removes that 'useless' options. Is that right ?

[janwijbrand]

I did add not a new test indeed. I considered having had to update the existing test

buildout/src/zc/buildout/tests/easy_install.txt

Line 709 in 3b14c31

# The Python interpreter wrapper allows some of the options that a

to be sufficient and also to express the intention. If someone were to remove the "useless" option, the test would fail. Right?