Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Mon, Feb 23, 2015 at 8:24 PM, Paul Moore wrote: > On 23 February 2015 at 19:01, Daniel Holth wrote: > > Sounds reasonable. It could be done by just reading the entire file > > contents after the shebang and re-writing them with the necessary > > offset all in RAM, truncating the file if necessary, without involving > > the zipfile module very much; the shebang could have some amount of > > padding by default; the file could just be re-compressed in memory > > depending on your appetite for complexity. > > The biggest problem with that is finding the end of the prefix data. > Frankly it's easier just to write a new prefix then use the zipfile > module to rewrite all of the content. That's what the current code > does writing to a new file. I don't think you need to rewrite all of the contents, if you don't mind poking into zipfile internals: endrec = zipfile._EndRecData(f) prefix_length = endrec[zipfile._ECD_LOCATION] - endrec[zipfile._ECD_SIZE] - endrec[zipfile._ECD_OFFSET] I do something similar to get at the prefix, although I need the zipfile opened anyway, so I use: endrec = zipfile._EndRecData(f) # pylint: disable=protected-access zf = zipfile.ZipFile(f) # endrec is None if reading it failed, but then ZipFile should have # raised an exception... assert endrec prefix_len = zf.start_dir - endrec[zipfile._ECD_OFFSET] # pylint: disable=protected-access 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/thomas%40python.org > -- Thomas Wouters Hi! I'm an email virus! Think twice before sending your email to help me spread! ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 23.02.15 21:22, Ethan Furman wrote: This could be a completely stupid question, but how does the zip file know where the individual files are? More to the point, does the index work via relative or absolute offset? If absolute, wouldn't the index have to be rewritten if the zip portion of the file moves? Absolute. ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 23 February 2015 at 19:47, Guido van Rossum wrote: > So is the PEP ready for pronouncement or should there be more discussion? I think Brett's idea is worth incorporating, so let's thrash that out first. > Also, do you have a BDFL-delegate or do you want me to review it? No-one has stepped up as BDFL-delegate, and there's no obvious candidate, so I think you're it, sorry :-) 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 23 February 2015 at 21:02, Brett Cannon wrote: >> The real problem with overwriting is if there's a failure during the >> overwrite you lose the original file. My original API had overwrite as >> the default, but I think the risk makes that a bad idea. > > > Couldn't you catch the exception, write the original file back out, and then > re-raise the exception? But you don't *have* the original file. You read the source archive entry-by-entry, not all at once. Apart from the implementation difficulty, this is getting too complex, and I think it's better to just give the user the tools to add whatever robustness or exception handling they want on top. 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 23 February 2015 at 21:18, Serhiy Storchaka wrote:
> On 23.02.15 22:51, Paul Moore wrote:
>>
>> BTW, while I was looking at the API, I realised I don't like the order
>> of arguments in pack(). I'm tempted to make it pack(directory,
>> target=None, interpreter=None, main=None) where a target of None means
>> "use the name of the source directory with .pyz tacked on", exactly as
>> for the command line API.
>
>
> If the order of arguments is not obvious, make them keyword-only.
To be honest, I don't think it *is* that non-obvious. I just think I
got it wrong initially.
With the new API, you have
pack('myappdir')
pack('myappdir', 'named_target.pyz')
Seems obvious enough to me. It matches the "source, destination" order
of similar functions like shutil.copy. And you can use a named
argument if you're not sure. But I don't think it's worth forcing it.
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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 24 February 2015 at 06:32, Paul Moore wrote: > On 23 February 2015 at 19:47, Guido van Rossum wrote: >> So is the PEP ready for pronouncement or should there be more discussion? > > I think Brett's idea is worth incorporating, so let's thrash that out first. > >> Also, do you have a BDFL-delegate or do you want me to review it? > > No-one has stepped up as BDFL-delegate, and there's no obvious > candidate, so I think you're it, sorry :-) If Guido isn't keen, I'd be willing to cover it as the current runpy module maintainer and the one that updated this part of the interpreter startup sequence to handle the switch to importlib in 3.3. The PEP itself doesn't actually touch any of that internal machinery though, it just makes the capability a bit more discoverable and user-friendly. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 24 February 2015 at 17:46, Guido van Rossum wrote: > I can do it but I don't want to be reviewing and accepting a PEP that's > still under discussion, and I don't have the bandwidth to follow the > discussion here -- I can only read the PEP. I will start that now. I'm just about to push an update based on Brett's comments, then it should be done. Can you hold off for a short while? Thanks. Paul. (Sorry, always the way - final comments appear as soon as you say "it's done" :-)) ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Tue, Feb 24, 2015 at 10:50 AM, Paul Moore wrote: > On 24 February 2015 at 18:24, Guido van Rossum wrote: > > Here's my review. I really like where this is going but I have a few > > questions and suggestions (I can't help myself :-). > > Thanks. > > > [I sneaked a peek at the update you sent to p...@python.org.] > > > > "Currently, pyyzer [5] and pex [6] are two tools known to exist." -> "... > > are two such tools." > > > > It's not stated whether the archive names include the .pyz[w] extension > or > > not (though I'm guessing it's not -- this should be stated). > > No, I assumed that automatically adding extensions is not the norm. A > lot of Windows tools do it, but I don't get the impression Unix tools > do. I'll clarify the wording. > > > The naming of the functions feels inconsistent -- maybe pack(directory, > > target) -> create_archive(directory, archive), and set_interpreter() -> > > copy_archive(archive, new_archive)? > > I'm OK with create_archive. But not so sure about copy_archive - the > purpose of that function is solely to change the shebang line on an > existing archive. It does so by copying, sure, but that's incidental. > I see get_interpreter/set_interpreter as complementary "helper" APIs, > and create_archive as the main API. > To me, the name set_() so strongly evokes the idea of in-place modification that I cannot live with it. (I also assume that your code won't do the right thing if the output is the same as the input, right?) > > Why no command-line equivalent for the other two methods? I propose the > > following interface: if there's only one positional argument, we're > asking > > to print its shebang line; if there are two and the input position is an > > archive instead of a directory, we're copying. (In the future people > will > > want an option to print more stuff, e.g. the main function or even a full > > listing.) > > Mainly because I couldn't think of an API that didn't look muddled, or > make the simple case of "I want to pack up a directory" look messy. > But I'll think about your proposal - it sounds nice, I'll see how it > fares when I try to implement it :-) > > > I've not seen the pkg.mod:fn notation before. Where is this taken from? > > Why can't it be pkg.mod.fn? > > It's common usage in setuptools and things like tat - it's the "entry > point" syntax used in packaging. I don't know of any reason why > all-dotted notation wouldn't work, though. I'll ask around if there's > any reason I'm not aware of. > OK, no need to change this then. > > I'd specify that when the output argument is a file open for writing, it > is > > the caller's responsibility to close the file. Also, can the file be a > > pipe? (I.e. are we using seek()/tell() or not?) And what about the > input > > archive? Can that be a file open for reading? > > I'll clarify all of these points. They are mostly "it can be whatever > the zipfile module accepts", though, which isn't explicitly stated > itself :-( > > The input can't be a file object for pack/create_archive because it's > a directory, not an archive, there. But it could be for > set_interpreter. I just wasn't sure if it was worth adding. It's not > hard to do, though. I'm not sure what use case this is addressing anyway, but assuming there is one, you might as well go all the way (except for directories, obviously). -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Feb 24, 2015, at 08:20 PM, Paul Moore wrote: >(side note: --python/-p or --interpreter/-i?) and set the entry point, Both virtualenv and (I think) pex use --python/-p so that seems to be the overwhelming trend . >To modify an archive could be done using > >python -m zipapp old.pyz new.pyz [-p interpreter] > >Default is to strip the shebang (no -p option). There's no option to >omit the target and do an inplace update because I feel the default >action (strip the shebang from the existing file with no backup) is >too dangerous. You have to be careful about the case where old.pyz == new.pyz (e.g. either handling this case safely or complaining loudly) , but also you could handle it by using a .tmp file and renaming. E.g. old.pyz -> old.pyz.bak and old.pyz.tmp -> old.pyz. >3. What to call the "show the shebang line" option I don't know how useful this is, given that (on *nix at least) you can effectively do the same with head(1). Cheers, -Barry ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Tue Feb 24 2015 at 3:21:30 PM Paul Moore wrote: > On 24 February 2015 at 18:58, Guido van Rossum wrote: > > Why no command-line equivalent for the other two methods? I propose the > > following interface: if there's only one positional argument, we're > asking > > to print its shebang line; if there are two and the input position is an > > archive instead of a directory, we're copying. (In the future people > will > > want an option to print more stuff, e.g. the main function or even a full > > listing.) > > Thinking about this, there are 3 main uses: > > 1. Create an archive > 2. Print the shebang > 3. Change the shebang > > Of these, (1) is the crucial one. > > Basic usage should be > > python -m zipapp mydir [-o anothername.pyz] [-p interpreter] [-m > entry:point] > > This zips up mydir to create an archive mydir.pyz. Options to change > the target name, set a shebang line (side note: --python/-p or > --interpreter/-i?) and set the entry point, > > I see this as pretty non-negotiable, this is the key use case that > needs to be as simple as possible. > > To print the shebang, we could use > > python -m zipapp myapp.pyz --show > > This allows for future expansion by adding options, although most > other things you might want to do (list the files, display > __main__.py) can be done with a standard zip utility. I'm not keen on > the option name --show, but I can't think of anything substantially > better. > > To modify an archive could be done using > > python -m zipapp old.pyz new.pyz [-p interpreter] > > Default is to strip the shebang (no -p option). There's no option to > omit the target and do an inplace update because I feel the default > action (strip the shebang from the existing file with no backup) is > too dangerous. > > To be explicit, "python -m zipapp app.pyz" will fail with a message > "In-place editing of python zip applications is not supported". > > That seems to work. > > Open questions: > > 1. To create an archive, use -o target for an explicit target name, or > just "target". The former is more conventional, the latter consistent > with modification. Or we could make modification use a (mandatory) -o > option. > EIBTI suggests requiring the -o. Pragmatic suggests just [in] [out] and use context based on what kind of thing [in] points at as well as whether -p is specified and whether it has an argument, which is the most minimal UX you can have. Question is whether you can screw up by specifying the wrong thing somehow (you might have to require that [out] doesn't already exist to make it work). > 2. -p/--python or -i/--interpreter for the shebang setting option > Since you are going to be using `python -m pyzip` then -i/--interpreter is less redundant-looking on the command-line. > 3. What to call the "show the shebang line" option As suggested above, -p w/o an argument could do it, otherwise --show or --info seems fine (I like --shebang, but that will probably be tough on non-English speakers). ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 02/24/2015 01:00 PM, Ethan Furman wrote: > On 02/24/2015 12:51 PM, Paul Moore wrote: >> $ python -m zipapp foo.pyz --info >> Interpreter: /usr/bin/python >> $ python -m zipapp bar.pyz --info >> Interpreter: Another way to support this is with subcommands. Have the default [implicit] command be to create the zip app, and then add any subcommands we need: python -m zipapp [create] foo #creates a foo.pyz from the foo directory python -m zipapp info foo.pyz # prints out shebang for foo.pyz python -m zipapp info --all foo.pyz # prints out shebang and directory structure and files and This easily leaves the door open to add new commands in the future if any are still needed, and makes the current commands easy and simple to use. -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 24 February 2015 at 21:09, Ethan Furman wrote: > Another way to support this is with subcommands. Have the default [implicit] > command be to create the zip app, and then > add any subcommands we need: > > python -m zipapp [create] foo #creates a foo.pyz from the foo directory > > python -m zipapp info foo.pyz # prints out shebang for foo.pyz > > python -m zipapp info --all foo.pyz # prints out shebang and directory > structure and files and > > This easily leaves the door open to add new commands in the future if any are > still needed, and makes the current > commands easy and simple to use. I didn't know an implicit subcommand was allowed. That would work, although it does mean that you can't build a pyz from a directory "info" without explicitly using the create subcommand. I think I'm going to go with "python -m zipapp foo.pyz --info" (And an -o option for the target, mandatory when the source is a pyz file, and --python for the interpreter). It's not set in stone yet, so if anyone objects, there's still time to change my mind. 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 25 Feb 2015 06:52, "Paul Moore" wrote: > > On 24 February 2015 at 20:32, Barry Warsaw wrote: > >>To modify an archive could be done using > >> > >>python -m zipapp old.pyz new.pyz [-p interpreter] > >> > >>Default is to strip the shebang (no -p option). There's no option to > >>omit the target and do an inplace update because I feel the default > >>action (strip the shebang from the existing file with no backup) is > >>too dangerous. > > > > You have to be careful about the case where old.pyz == new.pyz (e.g. either > > handling this case safely or complaining loudly) , but also you could handle > > it by using a .tmp file and renaming. E.g. old.pyz -> old.pyz.bak and > > old.pyz.tmp -> old.pyz. > > There are a *lot* of obscure failure modes here. What if old and new > are symlinks (or hard links) to the same file? What if a .tmp file > already exists? What if the user hits Ctrl-C at a bad moment? > > On the principle of keeping it simple, I prefer just requiring a > target, giving an error if the source name and target name are the > same (which still leaves loopholes for the determined fool on case > insensitive filesystems :-)) and just documenting that inplace > modification isn't supported. The PEP clearly states that it's > *minimal* tooling, after all... https://docs.python.org/3/library/os.path.html#os.path.samefile covers this check in a robust, cross-platform way. > >>3. What to call the "show the shebang line" option > > > > I don't know how useful this is, given that (on *nix at least) you can > > effectively do the same with head(1). > > I don't think it's that useful, TBH (although will head not print > binary junk if there is no shebang line?) I quite like Brett's > suggestion of --info, and maybe be a bit verbose: > > $ python -m zipapp foo.pyz --info > Interpreter: /usr/bin/python > $ python -m zipapp bar.pyz --info > Interpreter: > > I can't see it being useful for scripting, and if it matters, there's > always get_interpreter() then. It's mainly just as a diagnostic for > people who are getting the wrong interpreter invoked. The corresponding CLI option for the inspect module is "--details": https://docs.python.org/3/library/inspect.html#command-line-interface (By default "python -m inspect " prints the module source code) Cheers, Nick. > > 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
Maybe just fail if the target name already exists? On Tue, Feb 24, 2015 at 12:51 PM, Paul Moore wrote: > On 24 February 2015 at 20:32, Barry Warsaw wrote: > >>To modify an archive could be done using > >> > >>python -m zipapp old.pyz new.pyz [-p interpreter] > >> > >>Default is to strip the shebang (no -p option). There's no option to > >>omit the target and do an inplace update because I feel the default > >>action (strip the shebang from the existing file with no backup) is > >>too dangerous. > > > > You have to be careful about the case where old.pyz == new.pyz (e.g. > either > > handling this case safely or complaining loudly) , but also you could > handle > > it by using a .tmp file and renaming. E.g. old.pyz -> old.pyz.bak and > > old.pyz.tmp -> old.pyz. > > There are a *lot* of obscure failure modes here. What if old and new > are symlinks (or hard links) to the same file? What if a .tmp file > already exists? What if the user hits Ctrl-C at a bad moment? > > On the principle of keeping it simple, I prefer just requiring a > target, giving an error if the source name and target name are the > same (which still leaves loopholes for the determined fool on case > insensitive filesystems :-)) and just documenting that inplace > modification isn't supported. The PEP clearly states that it's > *minimal* tooling, after all... > > > > >>3. What to call the "show the shebang line" option > > > > I don't know how useful this is, given that (on *nix at least) you can > > effectively do the same with head(1). > > I don't think it's that useful, TBH (although will head not print > binary junk if there is no shebang line?) I quite like Brett's > suggestion of --info, and maybe be a bit verbose: > > $ python -m zipapp foo.pyz --info > Interpreter: /usr/bin/python > $ python -m zipapp bar.pyz --info > Interpreter: > > I can't see it being useful for scripting, and if it matters, there's > always get_interpreter() then. It's mainly just as a diagnostic for > people who are getting the wrong interpreter invoked. > > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 24.02.15 21:01, Guido van Rossum wrote: On Tue, Feb 24, 2015 at 10:50 AM, Paul Moore mailto:p.f.mo...@gmail.com>> wrote: On 24 February 2015 at 18:24, Guido van Rossum mailto:gu...@python.org>> wrote: > I'd specify that when the output argument is a file open for writing, it is > the caller's responsibility to close the file. Also, can the file be a > pipe? (I.e. are we using seek()/tell() or not?) And what about the input > archive? Can that be a file open for reading? I'll clarify all of these points. They are mostly "it can be whatever the zipfile module accepts", though, which isn't explicitly stated itself :-( See issue23252. https://bugs.python.org/issue23252 ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 24 February 2015 at 18:58, Guido van Rossum wrote: > The naming of the functions feels inconsistent -- maybe pack(directory, > target) -> create_archive(directory, archive), and set_interpreter() -> > copy_archive(archive, new_archive)? One possible source of confusion with copy_archive (and its command line equivalent "python -m zipapp old.pyz -o new.pyz") is that it isn't technically a copy, as it changes the shebang line (if you omit the interpreter argument it removes the existing shebang). We could change it to copy by default, but (a) that's redundant as a file copy works better, and (b) we'd need to add a method of specifying "remove the shebang" to replace omitting the interpreter arg. Is this a big enough issue to be worth changing the name of the function and the command line behaviour? I'm inclined to leave it, but mainly on the basis that I feel like I'm getting to the point of over-thinking things... 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 24 February 2015 at 18:58, Guido van Rossum wrote: > The naming of the functions feels inconsistent -- maybe pack(directory, > target) -> create_archive(directory, archive), and set_interpreter() -> > copy_archive(archive, new_archive)? Paul Moore wrote: > One possible source of confusion with copy_archive (and its command > line equivalent "python -m zipapp old.pyz -o new.pyz") is that it > isn't technically a copy, as it changes the shebang line (if you omit > the interpreter argument it removes the existing shebang). Is the difference between create and copy important? e.g., is there anything wrong with create_archive(old_archive, output=new_archive) working as well as create_archive(directory, archive)? -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 25 February 2015 at 16:02, Jim J. Jewett wrote: > On 24 February 2015 at 18:58, Guido van Rossum wrote: >> The naming of the functions feels inconsistent -- maybe pack(directory, >> target) -> create_archive(directory, archive), and set_interpreter() -> >> copy_archive(archive, new_archive)? > > > Paul Moore wrote: >> One possible source of confusion with copy_archive (and its command >> line equivalent "python -m zipapp old.pyz -o new.pyz") is that it >> isn't technically a copy, as it changes the shebang line (if you omit >> the interpreter argument it removes the existing shebang). > > Is the difference between create and copy important? e.g., is there > anything wrong with > > create_archive(old_archive, output=new_archive) working as well as > create_archive(directory, archive)? Probably not, now. The semantics have converged enough that this might be reasonable. It's how the command line interface works, after all. It would mean that the behaviour would be different depending on the value of the source argument (supplying the main argument and omitting the target are only valid for create), but again that's how the command line works. I'll have a go at implementing this change this evening and see how it plays out. 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 25 February 2015 at 17:06, Paul Moore wrote: >> Is the difference between create and copy important? e.g., is there >> anything wrong with >> >> create_archive(old_archive, output=new_archive) working as well as >> create_archive(directory, archive)? > > Probably not, now. The semantics have converged enough that this might > be reasonable. It's how the command line interface works, after all. > It would mean that the behaviour would be different depending on the > value of the source argument (supplying the main argument and omitting > the target are only valid for create), but again that's how the > command line works. > > I'll have a go at implementing this change this evening and see how it > plays out. That worked out pretty well, IMO. The resulting API is a lot cleaner (internally, there's not much change, I still have a copy_archive function but it's now private). I've included the resulting API documentation below. It looks pretty good to me. Does anyone have any further suggestions or comments, or does this look ready to go back to Guido for a second review? Paul Python API -- The module defines two convenience functions: .. function:: create_archive(directory, target=None, interpreter=None, main=None) Create an application archive from *source*. The source can be any of the following: * The name of a directory, in which case a new application archive will be created from the content of that directory. * The name of an existing application archive file, in which case the file is copied to the target. The file name should include the ``.pyz`` extension, if required. * A file object open for reading in bytes mode. The content of the file should be an application archive, and the file object is assumed to be positioned at the start of the archive. The *target* argument determines where the resulting archive will be written: * If it is the name of a file, the archive will be written to that file. * If it is an open file object, the archive will be written to that file object, which must be open for writing in bytes mode. * If the target is omitted (or None), the source must be a directory and the target will be a file with the same name as the source, with a ``.pyz`` extension added. The *interpreter* argument specifies the name of the Python interpreter with which the archive will be executed. It is written as a "shebang" line at the start of the archive. On POSIX, this will be interpreted by the OS, and on Windows it will be handled by the Python launcher. Omitting the *interpreter* results in no shebang line being written. If an interpreter is specified, and the target is a filename, the executable bit of the target file will be set. The *main* argument specifies the name of a callable which will be used as the main program for the archive. It can only be specified if the source is a directory, and the source does not already contain a ``__main__.py`` file. The *main* argument should take the form "pkg.module:callable" and the archive will be run by importing "pkg.module" and executing the given callable with no arguments. It is an error to omit *main* if the source is a directory and does not contain a ``__main__.py`` file, as otherwise the resulting archive would not be executable. If a file object is specified for *source* or *target*, it is the caller's responsibility to close it after calling create_archive. When copying an existing archive, file objects supplied only need ``read`` and ``readline``, or ``write`` methods. When creating an archive from a directory, if the target is a file object it will be passed to the ``zipfile.ZipFile`` class, and must supply the methods needed by that class. .. function:: get_interpreter(archive) Return the interpreter specified in the ``#!`` line at the start of the archive. If there is no ``#!`` line, return :const:`None`. The *archive* argument can be a filename or a file-like object open for reading in bytes mode. It is assumed to be at the start of the archive. ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Wed, Feb 25, 2015 at 2:33 PM Paul Moore wrote: > On 25 February 2015 at 17:06, Paul Moore wrote: > >> Is the difference between create and copy important? e.g., is there > >> anything wrong with > >> > >> create_archive(old_archive, output=new_archive) working as well as > >> create_archive(directory, archive)? > > > > Probably not, now. The semantics have converged enough that this might > > be reasonable. It's how the command line interface works, after all. > > It would mean that the behaviour would be different depending on the > > value of the source argument (supplying the main argument and omitting > > the target are only valid for create), but again that's how the > > command line works. > > > > I'll have a go at implementing this change this evening and see how it > > plays out. > > That worked out pretty well, IMO. The resulting API is a lot cleaner > (internally, there's not much change, I still have a copy_archive > function but it's now private). I've included the resulting API > documentation below. It looks pretty good to me. > > Does anyone have any further suggestions or comments, or does this > look ready to go back to Guido for a second review? > +1 from me. -Brett > > Paul > > Python API > -- > > The module defines two convenience functions: > > > .. function:: create_archive(directory, target=None, interpreter=None, > main=None) > >Create an application archive from *source*. The source can be any >of the following: > >* The name of a directory, in which case a new application archive > will be created from the content of that directory. >* The name of an existing application archive file, in which case the > file is copied to the target. The file name should include the > ``.pyz`` extension, if required. >* A file object open for reading in bytes mode. The content of the > file should be an application archive, and the file object is > assumed to be positioned at the start of the archive. > >The *target* argument determines where the resulting archive will be >written: > >* If it is the name of a file, the archive will be written to that > file. >* If it is an open file object, the archive will be written to that > file object, which must be open for writing in bytes mode. >* If the target is omitted (or None), the source must be a directory > and the target will be a file with the same name as the source, with > a ``.pyz`` extension added. > >The *interpreter* argument specifies the name of the Python >interpreter with which the archive will be executed. It is written as >a "shebang" line at the start of the archive. On POSIX, this will be >interpreted by the OS, and on Windows it will be handled by the Python >launcher. Omitting the *interpreter* results in no shebang line being >written. If an interpreter is specified, and the target is a >filename, the executable bit of the target file will be set. > >The *main* argument specifies the name of a callable which will be >used as the main program for the archive. It can only be specified if >the source is a directory, and the source does not already contain a >``__main__.py`` file. The *main* argument should take the form >"pkg.module:callable" and the archive will be run by importing >"pkg.module" and executing the given callable with no arguments. It >is an error to omit *main* if the source is a directory and does not >contain a ``__main__.py`` file, as otherwise the resulting archive >would not be executable. > >If a file object is specified for *source* or *target*, it is the >caller's responsibility to close it after calling create_archive. > >When copying an existing archive, file objects supplied only need >``read`` and ``readline``, or ``write`` methods. When creating an >archive from a directory, if the target is a file object it will be >passed to the ``zipfile.ZipFile`` class, and must supply the methods >needed by that class. > > .. function:: get_interpreter(archive) > >Return the interpreter specified in the ``#!`` line at the start of the >archive. If there is no ``#!`` line, return :const:`None`. >The *archive* argument can be a filename or a file-like object open >for reading in bytes mode. It is assumed to be at the start of the > archive. > ___ > 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/ > brett%40python.org > ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Feb 25, 2015, at 07:33 PM, Paul Moore wrote: >The module defines two convenience functions: > > >.. function:: create_archive(directory, target=None, interpreter=None, >main=None) > > Create an application archive from *source*. The source can be any > of the following: I think you meant s/directory/source/ in the signature. Other than that, +1. Cheers, -Barry ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore wrote: > On 25 February 2015 at 17:06, Paul Moore wrote: > I've included the resulting API > documentation below. It looks pretty good to me. Me too. I have a few nits anyhow. > .. function:: create_archive(directory, target=None, interpreter=None, > main=None) >Create an application archive from *source*. The source can be any >of the following: (1) *source* makes me think of source code, as opposed to binary. This is only a small objection, in part because I can't think of anything better. (2) If you do keep *source*, I think that the the "directory" parameter should be renamed to "source". (3) >* The name of an existing application archive file, in which case the > file is copied to the target. ==> >* The name of an existing application archive file, in which case the > file is copied (possibly with changes) to the target. My concern is that someone who does want just another copy will use this, see "copied", not read the other options, and be surprised when the shebang is dropped. >* A file object open for reading in bytes mode. The content of the > file should be an application archive, and the file object is > assumed to be positioned at the start of the archive. I like this way of ducking the "does it need to be seekable" question. >The *target* argument determines where the resulting archive will be >written: > >* If it is the name of a file, the archive will be written to that > file. (4) Note that the filename is not required to end with pyz, although that is good practice. Or maybe just be explicit that the function itself does not add a .pyz, and assumes that the caller will do so when appropriate. >The *interpreter* argument specifies the name of the Python >interpreter with which the archive will be executed. ... > ... Omitting the *interpreter* results in no shebang line being >written. (5) even if there was an explicit shebang line in the source archive. > If an interpreter is specified, and the target is a >filename, the executable bit of the target file will be set. (6) (target is a filename, or None) Or does that clarification just confuse the issue, and only benefit people so careful they'll verify it themselves anyway? (7) That is a good idea, but not quite as clear cut as it sounds. On unix, there are generally 3 different executable bits specifying *who* can run it. Setting the executable bit only for the owner is probably a conservative but sensible default. -jJ ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 25 February 2015 at 20:12, Jim J. Jewett wrote: > On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore wrote: >> On 25 February 2015 at 17:06, Paul Moore wrote: > >> I've included the resulting API >> documentation below. It looks pretty good to me. > > Me too. I have a few nits anyhow. > >> .. function:: create_archive(directory, target=None, interpreter=None, >> main=None) > >>Create an application archive from *source*. The source can be any >>of the following: > > (1) *source* makes me think of source code, as opposed to binary. > This is only a small objection, in part because I can't think of > anything better. > > (2) If you do keep *source*, I think that the the "directory" > parameter should be renamed to "source". Yep, that's a typo. Think of it as source -> target as opposed to source code and it's fine :-) > (3) >>* The name of an existing application archive file, in which case the >> file is copied to the target. > > ==> > >>* The name of an existing application archive file, in which case the >> file is copied (possibly with changes) to the target. > > My concern is that someone who does want just another copy will use > this, see "copied", not read the other options, and be surprised when > the shebang is dropped. Hmm, how about "... the content of the archive is copied to the target with a replacement shebang line"? > >>* A file object open for reading in bytes mode. The content of the >> file should be an application archive, and the file object is >> assumed to be positioned at the start of the archive. > > I like this way of ducking the "does it need to be seekable" question. :-) >>The *target* argument determines where the resulting archive will be >>written: >> >>* If it is the name of a file, the archive will be written to that >> file. > > (4) Note that the filename is not required to end with pyz, although > that is good practice. Or maybe just be explicit that the function > itself does not add a .pyz, and assumes that the caller will do so > when appropriate. Hmm, I thought I'd added an explanation. Maybe I did that somewhere else and missed it here. I'll clarify. >>The *interpreter* argument specifies the name of the Python >>interpreter with which the archive will be executed. ... >> ... Omitting the *interpreter* results in no shebang line being >>written. > > (5) even if there was an explicit shebang line in the source archive. I'll clarify the wording. >> If an interpreter is specified, and the target is a >>filename, the executable bit of the target file will be set. > > (6) (target is a filename, or None) Or does that clarification just > confuse the issue, and only benefit people so careful they'll verify > it themselves anyway? Probably :-) How about "if the target is a real file" or "unless the target is a file-like object"? But in all honesty I think it's fine as is. > (7) That is a good idea, but not quite as clear cut as it sounds. On > unix, there are generally 3 different executable bits specifying *who* > can run it. Setting the executable bit only for the owner is probably > a conservative but sensible default. I know, but excuse the naivete of a Windows user. I'm inclined to leave it as it is and direct people to read the source if they care that much (I actually used I_EXEC, which is what I've seen other code use). The alternative is to not set the executable bit at all and make the user do it as a separate step. My instinct is that doing that would be less user friendly, but my instincts on what's good Unix behaviour aren't strong... Thanks for the comments. 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 24 February 2015 at 18:24, Guido van Rossum wrote: > Here's my review. I really like where this is going but I have a few > questions and suggestions (I can't help myself :-). OK, I've updated both the PEP and the patch based on follow-up discussions. I think (again!) it is ready to go. I've included the updated PEP inline below, it'll be available at peps.python.org as soon as someone has a chance to upload it. Thanks to everyone for the various comments. If I've missed anything that someone thinks I'd said I would change, please let me know. Paul PEP: 441 Title: Improving Python ZIP Application Support Version: $Revision$ Last-Modified: $Date$ Author: Daniel Holth , Paul Moore Discussions-To: https://mail.python.org/pipermail/python-dev/2015-February/138277.html Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30 March 2013 Post-History: 30 March 2013, 1 April 2013, 16 February 2015 Improving Python ZIP Application Support Python has had the ability to execute directories or ZIP-format archives as scripts since version 2.6 [1]_. When invoked with a zip file or directory as its first argument the interpreter adds that directory to sys.path and executes the ``__main__`` module. These archives provide a great way to publish software that needs to be distributed as a single file script but is complex enough to need to be written as a collection of modules. This feature is not as popular as it should be mainly because it was not promoted as part of Python 2.6 [2]_, so that it is relatively unknown, but also because the Windows installer does not register a file extension (other than ``.py``) for this format of file, to associate with the launcher. This PEP proposes to fix these problems by re-publicising the feature, defining the ``.pyz`` and ``.pyzw`` extensions as "Python ZIP Applications" and "Windowed Python ZIP Applications", and providing some simple tooling to manage the format. A New Python ZIP Application Extension == The terminology "Python Zip Application" will be the formal term used for a zip-format archive that contains Python code in a form that can be directly executed by Python (specifically, it must have a ``__main__.py`` file in the root directory of the archive). The extension ``.pyz`` will be formally associated with such files. The Python 3.5 installer will associate ``.pyz`` and ``.pyzw`` "Python Zip Applications" with the platform launcher so they can be executed. A ``.pyz`` archive is a console application and a ``.pyzw`` archive is a windowed application, indicating whether the console should appear when running the app. On Unix, it would be ideal if the ``.pyz`` extension and the name "Python Zip Application" were registered (in the mime types database?). However, such an association is out of scope for this PEP. Python Zip applications can be prefixed with a ``#!`` line pointing to the correct Python interpreter and an optional explanation:: #!/usr/bin/env python3 # Python application packed with zipapp module (binary contents of archive) On Unix, this allows the OS to run the file with the correct interpreter, via the standard "shebang" support. On Windows, the Python launcher implements shebang support. However, it is always possible to execute a ``.pyz`` application by supplying the filename to the Python interpreter directly. As background, ZIP archives are defined with a footer containing relative offsets from the end of the file. They remain valid when concatenated to the end of any other file. This feature is completely standard and is how self-extracting ZIP archives and the bdist_wininst installer format work. Minimal Tooling: The zipapp Module == This PEP also proposes including a module for working with these archives. The module will contain functions for working with Python zip application archives, and a command line interface (via ``python -m zipapp``) for their creation and manipulation. More complete tools for managing Python Zip Applications are encouraged as 3rd party applications on PyPI. Currently, pyzzer [5]_ and pex [6]_ are two such tools. Module Interface The zipapp module will provide the following functions: ``create_archive(source, target=None, interpreter=None, main=None)`` Create an application archive from *source*. The source can be any of the following: * The name of a directory, in which case a new application archive will be created from the content of that directory. * The name of an existing application archive file, in which case the file is copied to the target. The file name should include the ``.pyz`` extension, if required. * A file object open for reading in bytes mode. The content of the file should be an application archive, and the file object is assum
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 2/26/2015 9:05 AM, Paul Moore wrote: On 24 February 2015 at 18:24, Guido van Rossum wrote: Here's my review. I really like where this is going but I have a few questions and suggestions (I can't help myself :-). OK, I've updated both the PEP and the patch based on follow-up discussions. I think (again!) it is ready to go. I've included the updated PEP inline below, it'll be available at peps.python.org as soon as someone has a chance to upload it. Thanks to everyone for the various comments. If I've missed anything that someone thinks I'd said I would change, please let me know. Three very, very, very minor nits below. Paul PEP: 441 Title: Improving Python ZIP Application Support Version: $Revision$ Last-Modified: $Date$ Author: Daniel Holth , Paul Moore Discussions-To: https://mail.python.org/pipermail/python-dev/2015-February/138277.html Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30 March 2013 Post-History: 30 March 2013, 1 April 2013, 16 February 2015 Improving Python ZIP Application Support Python has had the ability to execute directories or ZIP-format archives as scripts since version 2.6 [1]_. When invoked with a zip file or directory as its first argument the interpreter adds that directory to sys.path and executes the ``__main__`` module. These archives provide a great way to publish software that needs to be distributed as a single file script but is complex enough to need to be written as a collection of modules. This feature is not as popular as it should be mainly because it was not promoted as part of Python 2.6 [2]_, so that it is relatively unknown, but also because the Windows installer does not register a file extension (other than ``.py``) for this format of file, to associate with the launcher. This PEP proposes to fix these problems by re-publicising the feature, defining the ``.pyz`` and ``.pyzw`` extensions as "Python ZIP Applications" and "Windowed Python ZIP Applications", and providing some simple tooling to manage the format. A New Python ZIP Application Extension == The terminology "Python Zip Application" will be the formal term used for a zip-format archive that contains Python code in a form that can be directly executed by Python (specifically, it must have a ``__main__.py`` file in the root directory of the archive). The extension ``.pyz`` will be formally associated with such files. The Python 3.5 installer will associate ``.pyz`` and ``.pyzw`` "Python Zip Applications" with the platform launcher so they can be executed. A ``.pyz`` archive is a console application and a ``.pyzw`` archive is a windowed application, indicating whether the console should appear when running the app. On Unix, it would be ideal if the ``.pyz`` extension and the name "Python Zip Application" were registered (in the mime types database?). However, such an association is out of scope for this PEP. Python Zip applications can be prefixed with a ``#!`` line pointing to the correct Python interpreter and an optional explanation:: #!/usr/bin/env python3 # Python application packed with zipapp module (binary contents of archive) On Unix, this allows the OS to run the file with the correct interpreter, via the standard "shebang" support. On Windows, the Python launcher implements shebang support. However, it is always possible to execute a ``.pyz`` application by supplying the filename to the Python interpreter directly. As background, ZIP archives are defined with a footer containing relative offsets from the end of the file. They remain valid when concatenated to the end of any other file. This feature is completely standard and is how self-extracting ZIP archives and the bdist_wininst installer format work. Minimal Tooling: The zipapp Module == This PEP also proposes including a module for working with these archives. The module will contain functions for working with Python zip application archives, and a command line interface (via ``python -m zipapp``) for their creation and manipulation. More complete tools for managing Python Zip Applications are encouraged as 3rd party applications on PyPI. Currently, pyzzer [5]_ and pex [6]_ are two such tools. Module Interface The zipapp module will provide the following functions: ``create_archive(source, target=None, interpreter=None, main=None)`` Create an application archive from *source*. The source can be any of the following: * The name of a directory, in which case a new application archive will be created from the content of that directory. * The name of an existing application archive file, in which case the file is copied to the target. The file name should include the ``.pyz`` extension, if required. Or ".pyzw", I presume. * A file object ope
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 02/26/2015 09:28 AM, Glenn Linderman wrote: > On 2/26/2015 9:05 AM, Paul Moore wrote: >> ``create_archive(source, target=None, interpreter=None, main=None)`` >> >> >> Create an application archive from *source*. The source can be any >> of the following: >> >> * The name of a directory, in which case a new application archive >> will be created from the content of that directory. >> * The name of an existing application archive file, in which case the >> file is copied to the target. The file name should include the >> ``.pyz`` extension, if required. > > Or ".pyzw", I presume. Hmm -- can the py launcher handle a `#!pythonw` line to properly launch a .pyz (or .py) file? -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 26 February 2015 at 17:28, Glenn Linderman wrote: > * The name of a directory, in which case a new application archive > will be created from the content of that directory. > * The name of an existing application archive file, in which case the > file is copied to the target. The file name should include the > ``.pyz`` extension, if required. > > > Or ".pyzw", I presume. Yes. > * If it is an open file object, the archive will be written to that > file object, which must be open for writing in bytes mode. > * If the target is omitted (or None), the source must be a directory > and the target will be a file with the same name as the source, with > a ``.pyz`` extension added. > > > Hmm. So one _must_ specify a target if one wants a .pyzw. Correct. Generally I don't think pyzw will be used often, so I don't see that as a major problem. I'll add a clarifying note if the PEP needs another round of edits, but I'm inclined not to bother the PEP editors if this is all that needs changing. > The destination archive will have the specified name. The > given name will be used as written, so should include the > ".pyz" extension. > > > Or ".pyzw", I presume. You used ``funny quotes`` around extensions earlier, > but not here. Again yes. Normal quotes because this chunk is already in a literal block, so ``...`` is redundant. 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 26 February 2015 at 18:23, Ethan Furman wrote: > On 02/26/2015 09:28 AM, Glenn Linderman wrote: >> On 2/26/2015 9:05 AM, Paul Moore wrote: > >>> ``create_archive(source, target=None, interpreter=None, main=None)`` >>> >>> >>> Create an application archive from *source*. The source can be any >>> of the following: >>> >>> * The name of a directory, in which case a new application archive >>> will be created from the content of that directory. >>> * The name of an existing application archive file, in which case the >>> file is copied to the target. The file name should include the >>> ``.pyz`` extension, if required. >> >> Or ".pyzw", I presume. > > Hmm -- can the py launcher handle a `#!pythonw` line to properly launch a > .pyz (or .py) file? No. The launcher doesn't handle pythonw, because it won't do what you expect. On Windows, the difference between a GUI and a console program is baked into the executable (the "subsystem" field in the exe file header). That's why we have python/pythonw and py/pyw executables. A .pyz with a #!pythonw shebang would be run by py.exe, which would launch pythonw.exe. So if you double click the file, a console window will open (for py.exe) but the script won't use it (because it's being run by pythonw). So you'll have a useless console window hanging round. 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
Accepted! Thanks for your patience, Paul, and thanks everyone for their feedback. I know there are still a few small edits to the PEP, but those don't affect my acceptance. Congrats! --Guido On Thu, Feb 26, 2015 at 9:05 AM, Paul Moore wrote: > On 24 February 2015 at 18:24, Guido van Rossum wrote: > > Here's my review. I really like where this is going but I have a few > > questions and suggestions (I can't help myself :-). > > OK, I've updated both the PEP and the patch based on follow-up > discussions. I think (again!) it is ready to go. > > I've included the updated PEP inline below, it'll be available at > peps.python.org as soon as someone has a chance to upload it. > > Thanks to everyone for the various comments. If I've missed anything > that someone thinks I'd said I would change, please let me know. > > Paul > > PEP: 441 > Title: Improving Python ZIP Application Support > Version: $Revision$ > Last-Modified: $Date$ > Author: Daniel Holth , > Paul Moore > Discussions-To: > https://mail.python.org/pipermail/python-dev/2015-February/138277.html > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 30 March 2013 > Post-History: 30 March 2013, 1 April 2013, 16 February 2015 > > Improving Python ZIP Application Support > > > Python has had the ability to execute directories or ZIP-format > archives as scripts since version 2.6 [1]_. When invoked with a zip > file or directory as its first argument the interpreter adds that > directory to sys.path and executes the ``__main__`` module. These > archives provide a great way to publish software that needs to be > distributed as a single file script but is complex enough to need to > be written as a collection of modules. > > This feature is not as popular as it should be mainly because it was > not promoted as part of Python 2.6 [2]_, so that it is relatively > unknown, but also because the Windows installer does not register a > file extension (other than ``.py``) for this format of file, to associate > with the launcher. > > This PEP proposes to fix these problems by re-publicising the feature, > defining the ``.pyz`` and ``.pyzw`` extensions as "Python ZIP Applications" > and "Windowed Python ZIP Applications", and providing some simple > tooling to manage the format. > > A New Python ZIP Application Extension > == > > The terminology "Python Zip Application" will be the formal term used > for a zip-format archive that contains Python code in a form that can > be directly executed by Python (specifically, it must have a > ``__main__.py`` file in the root directory of the archive). The > extension ``.pyz`` will be formally associated with such files. > > The Python 3.5 installer will associate ``.pyz`` and ``.pyzw`` "Python > Zip Applications" with the platform launcher so they can be executed. > A ``.pyz`` archive is a console application and a ``.pyzw`` archive is a > windowed application, indicating whether the console should appear > when running the app. > > On Unix, it would be ideal if the ``.pyz`` extension and the name > "Python Zip Application" were registered (in the mime types database?). > However, such an association is out of scope for this PEP. > > Python Zip applications can be prefixed with a ``#!`` line > pointing to the correct Python interpreter and an optional > explanation:: > > #!/usr/bin/env python3 > # Python application packed with zipapp module > (binary contents of archive) > > On Unix, this allows the OS to run the file with the correct > interpreter, via the standard "shebang" support. On Windows, the > Python launcher implements shebang support. > > However, it is always possible to execute a ``.pyz`` application by > supplying the filename to the Python interpreter directly. > > As background, ZIP archives are defined with a footer containing > relative offsets from the end of the file. They remain valid when > concatenated to the end of any other file. This feature is completely > standard and is how self-extracting ZIP archives and the bdist_wininst > installer format work. > > > Minimal Tooling: The zipapp Module > == > > This PEP also proposes including a module for working with these > archives. The module will contain functions for working with Python > zip application archives, and a command line interface (via ``python > -m zipapp``) for their creation and manipulation. > > More complete tools for managing Python Zip Applications are > encouraged as 3rd party applications on PyPI. Currently, pyzzer [5]_ > and pex [6]_ are two such tools. > > Module Interface > > > The zipapp module will provide the following functions: > > ``create_archive(source, target=None, interpreter=None, main=None)`` > > > Create an application archive from *source*. The source can be any >
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 26 February 2015 at 21:34, Guido van Rossum wrote: > Accepted! > > Thanks for your patience, Paul, and thanks everyone for their feedback. > > I know there are still a few small edits to the PEP, but those don't affect > my acceptance. Congrats! Excellent, thanks to everyone for the helpful comments throughout. 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 26 February 2015 at 21:48, Paul Moore wrote: > On 26 February 2015 at 21:34, Guido van Rossum wrote: >> Accepted! >> >> Thanks for your patience, Paul, and thanks everyone for their feedback. >> >> I know there are still a few small edits to the PEP, but those don't affect >> my acceptance. Congrats! > > Excellent, thanks to everyone for the helpful comments throughout. I'm still looking for someone who has the time to commit the final patch on http://bugs.python.org/issue23491. Python 3.5a2 is due out today (at least according to the PEP) so I've probably missed that, but it would be nice if it could be in for alpha 3 at least. Thanks, 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Sun, Mar 8, 2015, 08:40 Paul Moore wrote: On 26 February 2015 at 21:48, Paul Moore wrote: > On 26 February 2015 at 21:34, Guido van Rossum wrote: >> Accepted! >> >> Thanks for your patience, Paul, and thanks everyone for their feedback. >> >> I know there are still a few small edits to the PEP, but those don't affect >> my acceptance. Congrats! > > Excellent, thanks to everyone for the helpful comments throughout. I'm still looking for someone who has the time to commit the final patch on http://bugs.python.org/issue23491. Python 3.5a2 is due out today (at least according to the PEP) so I've probably missed that, but it would be nice if it could be in for alpha 3 at least. If no one gets to it I can submit on Friday. -brett Thanks, 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/brett%40python.org ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Sun, Mar 8, 2015 at 10:35 AM Brett Cannon wrote: > > On Sun, Mar 8, 2015, 08:40 Paul Moore wrote: > > On 26 February 2015 at 21:48, Paul Moore wrote: > > On 26 February 2015 at 21:34, Guido van Rossum wrote: > >> Accepted! > >> > >> Thanks for your patience, Paul, and thanks everyone for their feedback. > >> > >> I know there are still a few small edits to the PEP, but those don't > affect > >> my acceptance. Congrats! > > > > Excellent, thanks to everyone for the helpful comments throughout. > > I'm still looking for someone who has the time to commit the final > patch on http://bugs.python.org/issue23491. Python 3.5a2 is due out > today (at least according to the PEP) so I've probably missed that, > but it would be nice if it could be in for alpha 3 at least. > > If no one gets to it I can submit on Friday. > Submitted in https://hg.python.org/cpython/rev/d1e9f337fea1 . Thanks for the hard work, 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
Huzzah! Thanks for working on this one folks, it should make the zipfile execution support much easier for current and future Python users to discover :) Cheers, Nick. ___ 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
Por favor quiero descargar este programa para mi teléfono Windows 8 Anais'Timaure♡___ 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
