Paul Moore wrote: > > On 12 February 2015 at 15:37, Steve Dower <steve.do...@microsoft.com> wrote: >> If venv's activate script sets it, I say go ahead and write it up. If >> it's just virtualenv, I'd rather not explicitly depend on it, >> especially since PEP 397's stated aim is file associations and not command > line. > > Yep, venv uses it too (see > https://hg.python.org/cpython/file/9e10c4255277/Lib/venv/scripts/nt/activate.bat). > > As people like Thomas (and me, until this issue stopped me :-)) are using the > launcher for command line use, I think it's fair to broaden the scope to make > command line usage more convenient. I agree that PEP > 397 was originally focused mainly on file associations, but I think it's worth > looking beyond that now.
That's roughly the premise behind my activate-py proposal. Use `activate` to make a virtualenv/venv the default, and `activate-py [-x[.y[-32]]]` to make a non-venv the default. I have proof of concept implementations already for cmd.exe and PowerShell and it's fairly simple, but writing up the rationale is time consuming (and also the main point - it's worth having all the problems with PATH documented in one place). >> I've been making changes to py.exe in hg.p.o, so I hope the standalone >> one is tracking. The msi for it as part of the official build can also >> standalone, so maybe we should merge the two? > > Hmm, sadly I don't think it is. Originally the standalone one was (I > believe) provided by Vinay for people using Pythons that didn't have it > bundled, > and to add features (such as the new file extensions) on a quicker timescale > than Python releases. But since he passed it to the pypa umbrella I don't > think > he's been keeping the two in sync. I've copied him in case I'm completely > wrong > on this. > > Personally if we now have a standalone launcher MSI, I'd like to discontinue > the > external one completely, and officially publish the standalone launcher MSI on > python.org as a service for users of older Pythons. There seems little reason > to > maintain 2 repos if we don't have to. We could merge in changes from the > external repo before discontinuing it, but I'm not sure how controversial that > would be (for example, would it need a PEP to include the 2 new extensions?) None of my installer changes so far have had a PEP, and only a few people have complained about that :) (it does have more documentation than I've ever written for an installer before though) IIRC, there was a PEP for executing ZIP files directly (2.6-era?), which I believe are the purpose of those extensions. If "py.exe spam.pyz" already works, I don't see any need for a PEP to add the association in the installer. Cheers, Steve > Paul _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
