Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

On Sat, Feb 14, 2015 at 11:07 AM, Nick Coghlan wrote: > OTOH, it may be time to reconsider our recommendation to distros as well, > suggesting that for Python 3.5+, we will consider it appropriate to have the > "python" symlink refer to "python3". If *all* distros provide a "python2" symlink, the

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

On 15 February 2015 at 21:00, Vinay Sajip wrote: >> The original PEP said nothing about a PATH search for #!/usr/bin/env >> python, so I mistakenly assumed there was no way currently to write a >> script that worked with an activated virtualenv. > > > Actually the path search was added later, by y

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

- Original Message - From: Paul Moore > The original PEP said nothing about a PATH search for #!/usr/bin/env > python, so I mistakenly assumed there was no way currently to write a > script that worked with an activated virtualenv. Actually the path search was added later, by you! See

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

On 15 February 2015 at 19:23, Vinay Sajip wrote: > Paul Moore gmail.com> writes: > >> 2. It would be a nice, although extremely obscure, feature to be able >> to allow people who want to keep Python off their path to set >> VIRTUAL_ENV but *not* set PATH, so that py.exe does the right thing >> bu

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15/02/2015 18:06, Steve Dower wrote: "Go ahead, make my pep." We should make a python-dev t-shirt with this on it :) I'll buy one provided p&p isn't too high :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence __

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

Paul Moore gmail.com> writes: > 2. It would be a nice, although extremely obscure, feature to be able > to allow people who want to keep Python off their path to set > VIRTUAL_ENV but *not* set PATH, so that py.exe does the right thing > but there's *still* no python.exe on PATH. Limit the depend

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15.02.15 18:21, Thomas Wouters wrote: which requires that extension modules are stored uncompressed (simple) and page-aligned (harder, as the zipfile.ZipFile class doesn't directly support page-aligning anything It is possible to add this feature to ZipFile. It can be useful because will al

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On Sun, Feb 15, 2015 at 5:43 PM, Paul Moore wrote: > On 15 February 2015 at 16:15, Petr Viktorin wrote: >> On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore wrote: >>> So the usage would be something like >>> >>> python -m zipapp [options] dir_to_zip >>> >>> Options: >>> -p The interpreter

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

"Go ahead, make my pep." We should make a python-dev t-shirt with this on it :) Top-posted from my Windows Phone From: Daniel Holth Sent: ‎2/‎15/‎2015 9:46 To: Nick Coghlan Cc: Paul Moore

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

Go ahead, make my pep. I will appreciate seeing it happen. On Feb 15, 2015 8:47 AM, "Nick Coghlan" wrote: > On 15 February 2015 at 23:21, Paul Moore wrote: > > On 15 February 2015 at 08:59, Nick Coghlan wrote: > >> The other option would to cut PEP 441 way back to *just* be about > >> standard

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore wrote: > So the usage would be something like > > python -m zipapp [options] dir_to_zip > > Options: > -p The interpreter to use on the shebang line > (defaulting to /usr/bin/env python) On many systems this default would mean Python 2. Even

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15 February 2015 at 16:21, Thomas Wouters wrote: > It might be nice to consider those use-cases in pyzapp as well, especially > once the glibc feature is released. It requires some fairly big changes to > zipimport (I ended up rewriting the whole thing) but we can easily > opensource the code,

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15 February 2015 at 16:15, Petr Viktorin wrote: > On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore wrote: >> So the usage would be something like >> >> python -m zipapp [options] dir_to_zip >> >> Options: >> -p The interpreter to use on the shebang line >> (defaulting to /usr/bin/env py

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15 February 2015 at 16:00, Serhiy Storchaka wrote: >> Would it be reasonable to add methods to the >> ZipFile class to read and write the prefix data? > > > But the stdlib zipfile module supports this. > > with open(filename, 'wb') as f: > f.write(shebang) > with zipfile.PyZipFile(f, 'a

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

FWIW, we have a similar tool to 'pyzaa' at Google, although a lot older (it has a pure-python implementation of zipimport, because it had to work with Python 2.2 back in the day) that *does* support extension modules and other shared libraries (by extracting them to disk on program startup.) We're

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15.02.15 10:47, Paul Moore wrote: On 15 February 2015 at 08:14, Paul Moore wrote: Maybe it would be better to put something on PyPI and let it develop outside the stdlib first? The only place where a ".pyz" file can't easily be manipulated with the stdlib zipfile module is in writing a she

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15 February 2015 at 13:47, Nick Coghlan wrote: > Or we just skip the wrapper and make "python -m zipapp" the > recommended invocation style. Adding a wrapper later is fairly easy, > but removing it would be difficult. Fine with me - the wrappers are basically useless on Windows where Tools/Scr

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15 February 2015 at 23:21, Paul Moore wrote: > On 15 February 2015 at 08:59, Nick Coghlan wrote: >> The other option would to cut PEP 441 way back to *just* be about >> standardising and registering the file associations, and recommending >> the use of pip to obtain the build machinery with (w

Re: [Python-Dev] PEP 486: Make the Python Launcher aware of virtual environments

On 13 February 2015 at 07:02, Nick Coghlan wrote: > Procedurally, since it's a Windows specific change, and assuming Guido > doesn't want to pronounce on this one himself, perhaps Steve Dower > would be an appropriate BDFL-Delegate? The PEP is now up to date and the patch is on the tracker at htt

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15 February 2015 at 08:59, Nick Coghlan wrote: > The other option would to cut PEP 441 way back to *just* be about > standardising and registering the file associations, and recommending > the use of pip to obtain the build machinery with (whether pyzaa, > pyzzer or Twitter's more comprehensive

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15 February 2015 at 18:14, Paul Moore wrote: > OTOH, if the pyz/pyzw extensions are already (or will be) registered > by the installer then the only remaining feature of this PEP [1] is > the archive creation app. And designing that as we go is probably the > wrong way to get something in the s

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15 February 2015 at 08:14, Paul Moore wrote: > Maybe it would be better to > put something on PyPI and let it develop outside the stdlib first? The only place where a ".pyz" file can't easily be manipulated with the stdlib zipfile module is in writing a shebang line to the start of the archive

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 15 February 2015 at 05:33, Nick Coghlan wrote: > I'd definitely prefer a simple procedural API like that over offering > a public stateful object-oriented API, as the latter significantly > increases testing complexity without offering a sufficiently > compelling gain in expressiveness to justi