If Activate.ps1 was made to not have substitutions upon generation and be an entirely static file, then the file could be signed and thus not require people to lower their security requirements in PowerShell in order to activate their virtual environments.

How would you plan to replace the functionality where the venv's bin path is substituted into the script? Purely through introspecting its own path?

I see that PowerShell is/will be portable to e.g. Linux environments, but I presume the security requirements you refer to are purely a Windows constraint - is that right?

> How would you plan to replace the functionality where the venv's bin path is substituted into the script? Purely through introspecting its own path?

It's stored in pyvenv.cfg.

> I presume the security requirements you refer to are purely a Windows constraint - is that right?

Yes (at least for now; not sure what PowerShell Core plans to do about this sort of thing long-term).

How will this interact with EnvBuilder.install_scripts() (which explicitly states that it performs textual substitution)?

Note that I'm not aware of anyone who actually uses the ability to subclass EnvBuilder, but I wouldn't be surprised to find that people do...

> It's stored in pyvenv.cfg.

Is it?

$ python3.8maint -m venv --prompt "foo bar" /tmp/venv
$ more /tmp/venv/pyvenv.cfg 
home = /home/vinay/projects/python/3.8
include-system-site-packages = false
version = 3.8.0
prompt = 'foo bar'

The source Python location is stored, but not, from what I can see, the venv path itself ... though of course that can be worked out from $PSScriptRoot or similar.

> How will this interact with EnvBuilder.install_scripts() (which explicitly states that it performs textual substitution)?

If there's nothing to substitute (because the script source has no placeholders), that won't constitute a problem, AFAIK.

One thing to note is that if we sign this file, it'll have to bypass the text substitution step completely to avoid modifying line endings or encoding. So there could be code changes in venv too.

This would be a great contribution from a PowerShell expert, and might be worth advertising (Twitter) for one. File parsing can get tricky quickly, but there are a few clever ways to approach it. We also need to set a minimum PowerShell version to support, as plenty of its features aren't available on base Windows 7 installs.

> How will this interact with EnvBuilder.install_scripts() (which explicitly states that it performs textual substitution)?

It won't, so that would have to change as well. As you mentioned, Paul, I don't know who even uses the functionality through a subclass, but since this is a security consideration I think it's worth changing.

> Is it?

Sorry, misread what you were asking. You're right it's not stored, but it can be worked out in other ways, e.g. from the location of pyvenv.cfg or Activate.ps1, etc.

> So there could be code changes in venv too.

Yep, hence making the issue now so that others talking about adding more substitution ideas know that there's talk going the other way and removing the substitution abilities.

> This would be a great contribution from a PowerShell expert, and might be worth advertising (Twitter) for one.

Already have a co-worker interested in working on it.

I just chatted with Derek about this, and while we identified some potential regressions (previously we were injecting str(prompt) into Activate.ps1, and now we're showing repr(prompt)), I don't think they're widely used.

For example, if you previously did:

>>> py -m venv --prompt "my`nprompt" env

You'd get 'my\nprompt' in pyvenv.cfg, but an actual newline in your printed prompt (note that passing "my\nprompt" in the command doesn't do this). There are likely other things that will be escaped in the configuration that previously would have been fine with the direct substitution.

I have no real sense of how widely used these are. They are definitely less popular than machines that are configured to require code-signed Powershell scripts, so we still come out ahead. It's probably easy to handle some of the more common escapes, if we know what they are, but I doubt we're going to reimplement full Python string parsing in a Powershell script.

Vinay - any thoughts here? For me, I think get it out in 3.8.0b4 and see how it fares.

New changeset 732775d6be8062e72cf4995d5a9db0170e22c233 by Steve Dower (Derek Keeler) in branch 'master':
bpo-37354: Make Powershell Activate.ps1 script static to allow for signing (GH-14967)
https://github.com/python/cpython/commit/732775d6be8062e72cf4995d5a9db0170e22c233

New changeset 0c64b57e0155c333b7c96ec2af009c1388cd5d31 by Steve Dower (Miss Islington (bot)) in branch '3.8':
[3.8] bpo-37354: Make Powershell Activate.ps1 script static to allow for signing (GH-14967)
https://github.com/python/cpython/commit/0c64b57e0155c333b7c96ec2af009c1388cd5d31

New changeset 3e34a25a7a5c9ea2c46f2daeeb60f072faa5aaa1 by Steve Dower in branch 'master':
bpo-37354: Sign Activate.ps1 for release (GH-15235)
https://github.com/python/cpython/commit/3e34a25a7a5c9ea2c46f2daeeb60f072faa5aaa1

Thanks, Derek!

New changeset 2b98d8ec7ec3d41c6403ff9f6677a00ea0cb8b92 by Miss Islington (bot) in branch '3.8':
bpo-37354: Sign Activate.ps1 for release (GH-15235)
https://github.com/python/cpython/commit/2b98d8ec7ec3d41c6403ff9f6677a00ea0cb8b92