The Scripts/bin thing is not specific to venv - for whatever reason, the original Windows implementation chose to use "Scripts" rather than "bin" for the executables directory under Windows, and I don't think it can be changed now without affecting backward compatibility. The venv code just fits into the existing, wider theme. My guess is you would need to propose a PEP to move everything over from "Scripts" to "bin" in the Windows Python world, and show that it would not break any existing code anywhere - seems like a tall order.

This issue was already rejected before you added your PR so I'm not sure why you went to the trouble of creating a PR. Thanks for trying to help, but I think this PR should be closed for the above reasons.

IMHO we should not copy, that would just be confusing. If anything we should make the bin folder a junction for the Scripts.

I don't think we don't want to junction "all" the files, only those that are bash-shell-related... otherwise we'd have to change the PEP and we're back to all the reasons why it was rejected in the first place.

A soft-link (if available) to bin/activate is OS-neutral, and allows the existing documentation to be factually correct (right now some documentation assumes bin/activate is available for bash..., which it isn't.)

Plus, junctions are not always available on all systems, although that's not my primary concern.

The primary issue is the thousands of developers around the world using bash in CI that have had to solve this rather absurd problem in thousands of different ways (if os == nt, if -e Scripts/ if uname == Linux, embedded in make files, embedded in bash scripts. I've seen them all.

The rest of Scripts/ belongs where it is.

The primary issue is the thousands of developers around the world using bash in CI that have had to solve this rather absurd problem in thousands of different ways

IMO, It's a platform difference. If you're developing on both Windows and Unix, you need to be aware of platform differences (even if you try to use some sort of Unix-lookalike that provides bash, it still can't hide the fact that you're not on Unix totally) and Scripts vs bin is just one of many such differences.

Yes, it's an absurd and annoying difference, but the reasons it exists are historical, and changing it now is (as @vsajip said) likely to be way too big an exercise. Patching over just one part of the problem may help some specific cases, but overall will be more confusing, not less. (Why is activate in bin, but not, for example, pip.exe? Why does activate add Scripts to PATH rather than bin?)

Plus, junctions are not always available on all systems, although that's not my primary concern.

I thought we only target here Windows, that always has junctions.

A soft-link (if available) to bin/activate is OS-neutral,

Soft links don't work always on Windows so that can't be.

right now some documentation assumes bin/activate is available for bash

Sounds to me like a bad assumption, and should be fixed in the documentation.

The only way I can see for us to improve on this is to generate the bin, but that mirrors and is always whatever Script is (aka Windows NTFS junction).