Support parsing PIP_RUN_RETENTION_STRATEGY from a script

[sirosen]

Consider scripts written and distributed amongst a development team with pip-run as the invocation method. Common dev requirements can document a requirement for pip-run.

Under these conditions, a "default" of PIP_RUN_MODE=persist is appropriate for making the scripts relatively efficient to run. This will give good performance behavior without assuming or requiring that everyone is setting PIP_RUN_MODE=persist in their shell profile.

Basically, I want to take the PIP_RUN_MODE env var from being the only source of truth to it being an override.
This would also allow PIP_RUN_MODE=ephemeral to be used as an explicit override.

There are at least two modes to support for specifying this: in a comment or via a special assignment.
Are there reasons not to implement this option? Additional considerations if I were to attempt to do this in a PR?

[jaraco]

An interesting idea. And definitely worth exploring. I do think it could be possible and reasonable to solicit the mode from the script, similar to how requirements and options are solicited. One concern is that it probably needs to be implemented for both supported forms of parsing, though I'd be okay with only supporting it as a "special assignment", maybe something like __run_mode__ = 'persist'.

Before we invest more in the name "mode", I wonder if there's a better name for the setting. Pip calls the directory a target. In virtualenv, it's called an env. If it's going to need a rename, it'll be preferable to do it prior to expanding its use.

My first reluctance to your proposal lies in how you're planning to use it. I know if it were my ecosystem, I'd be bothered by having to supply the same config repeatedly in each script. That makes me wonder if there's another approach that would enable you to apply the behavior more broadly, such as through a config file or an inferred behavior.

For example, maybe pip-run should use persist as the default mode if the requirements are found entirely in a script, or maybe only if that script is configured with a shebang (though that doesn't give Windows users access to the behavior).

If after considering these other options you're still inclined to add the setting to each script, feel free to proceed with other considerations and drafting a PR.

[sirosen]

If it's going to need a rename, it'll be preferable to do it prior to expanding its use.

Agreed. I'll start to think about names a bit. "persist" and "ephemeral" are both pretty good names for this setting, so I'm thinking about things like "persist=true" as well.

I know if it were my ecosystem, I'd be bothered by having to supply the same config repeatedly in each script. That makes me wonder if there's another approach that would enable you to apply the behavior more broadly, such as through a config file or an inferred behavior.

...

If after considering these other options you're still inclined to add the setting to each script, feel free to proceed with other considerations and drafting a PR.

I'm minimally bothered by having to repeat the config in each script. It avoids other issues and is pretty simple to understand and use.

Ideally I wouldn't have to, but I don't see an alternative which I prefer -- implicit logic risks getting it wrong for some users, and a config file raises questions like which file to use (pyproject.toml? might not be appropriate) and how to discover it relative to the script.

---

I'll try to find some time to play with this in a PR. I plan to support both parsing modes, but could revisit that if there are issues.

[jaraco]

I've filed a separate issue to track the consideration of renaming the variable. I don't want to block this issue, so let's proceed with MODE for now.