On 2/17/2015 1:40 PM, Barry Warsaw wrote:
I agree, for deployment to environments where you can guarantee that the basic
Python infrastructure is available. It may not be though, and perhaps we can
relegate that to py2exe, cx_freeze, and friends, although I would say that
having such support
On 17.02.15 23:25, Barry Warsaw wrote:
I'm not sure sys.getfilesystemencoding() is the right encoding, rather than
sys.getdefaultencoding(), if you're talking about the encoding of the shebang
line rather than the encoding of the resulting pyz filename.
On POSIX sys.getfilesystemencoding() is
Hi Zach,
I think it is best to remove the .spec file if it is not supported by Python
developers.It is misleading to ship unsupported file within source tree.
Thanks for reply.
From: Zachary Ware zachary.ware+py...@gmail.com
To: python-dev@python.org python-dev@python.org
Cc: Blaxton
On 17 February 2015 at 18:44, Barry Warsaw ba...@python.org wrote:
The broader question of pex, pyzaa, etc. is an important one for Python,
IMHO. Having a standard single-executable distribution story will help Python
continue to compete on platforms that work beyond the distribution models
On Feb 15, 2015, at 05:15 PM, Petr Viktorin wrote:
So I'd suggest `/usr/bin/env python3` for the default.
I really don't want `/usr/bin/env anything`.
In general, using /usr/bin/env is a fine tool for developers, but a terrible
tool for deployment. It's just too easy for end users to break an
I'm just now catching up on this thread, so hopefully these thoughts are still
relevant.
IIRC, the PEP has been scaled back to mostly a convenience around packing an
existing directory into a .pyz file, and (on Windows) adding an association
for those as executable Python zip file. To the extent
On Feb 16, 2015, at 04:16 PM, Paul Moore wrote:
So, the options I see:
1. Stick with /usr/bin/env python
2. No shebang unless -p is specified
3. Unix users come up with a solution which is the same as the above
for Windows users, but which suits them better.
#2 seems to me to be the most
On Feb 15, 2015, at 05:21 PM, Thomas Wouters wrote:
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
On Feb 16, 2015, at 11:21 PM, Paul Moore wrote:
Default Interpreter
---
The initial draft of this PEP proposed using ``/usr/bin/env python``
as the default interpreter.
The other reasonable alternative for a default shebang is sys.executable.
Cheers,
-Barry
On 17 February 2015 at 18:52, Barry Warsaw ba...@python.org wrote:
So, the options I see:
1. Stick with /usr/bin/env python
2. No shebang unless -p is specified
3. Unix users come up with a solution which is the same as the above
for Windows users, but which suits them better.
#2 seems to me to
On 17 February 2015 at 18:56, Barry Warsaw ba...@python.org wrote:
The initial draft of this PEP proposed using ``/usr/bin/env python``
as the default interpreter.
The other reasonable alternative for a default shebang is sys.executable.
That's instantly non-portable. On my PC, it'd give
On Feb 17, 2015, at 08:58 PM, Paul Moore wrote:
But I would say that anything that is added to zipimport should be
cross-platform. Having support for C extensions in zipimport on Unix
only will just add another way in which Python applications can
inadvertantly be non-portable... (It should be
On Feb 17, 2015, at 08:53 PM, Paul Moore wrote:
On 17 February 2015 at 18:56, Barry Warsaw ba...@python.org wrote:
The initial draft of this PEP proposed using ``/usr/bin/env python``
as the default interpreter.
The other reasonable alternative for a default shebang is sys.executable.
That's
On 17 February 2015 at 19:00, Barry Warsaw ba...@python.org 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
On 17 February 2015 at 18:44, Barry Warsaw ba...@python.org wrote:
I don't know exactly what the procedure would be to claim .pyz for *nix,
e.g. updating /etc/mime.types, but I think the PEP should at least mention
this. I think we want to get as official support for .pyz files on *nix as
On 02/17/2015 01:13 PM, Barry Warsaw wrote:
There are lots of interesting use cases we could still support. I could build
a single-file application and deploy it into my OS's system archives. I could
deploy that thing into my platform's app store. I could hand it over to a
colleague
On Feb 17, 2015, at 08:52 PM, Paul Moore wrote:
I'm pretty sure that's the way the general feeling is going.
Though the more I think about it, the more I like sys.executable. :)
However, -p must be able to accept any number of strings, including
/usr/bin/env python3 if the user wants that.
On Feb 17, 2015, at 08:44 PM, Paul Moore wrote:
I'd like to see a good single-file bundled application format for
Python (on Windows, there's py2exe, which is fantastic, but often I
simply don't *want* to bundle Python and the stdlib with my code).
I agree, for deployment to environments where
On 17 February 2015 at 21:13, Barry Warsaw ba...@python.org wrote:
Don't discount sys.executable to quickly. :)
I used pyzzer when it defaulted to sys.executable, and the experience
was painful. That's on Windows, and Unix may be different, but let's
just say I don't want to go there :-)
Paul
On 17 February 2015 at 21:10, Barry Warsaw ba...@python.org wrote:
The actual import an extension module support in zipimport does need to be
cross-platform, but it can work differently depending on the platform. For
example, if extended-dlopen is available on your Linux machine, zipimport
On Feb 17, 2015, at 01:25 PM, Ethan Furman wrote:
On 02/17/2015 01:13 PM, Barry Warsaw wrote:
There are lots of interesting use cases we could still support. I could
build a single-file application and deploy it into my OS's system archives.
I could deploy that thing into my platform's app
On 2/17/2015 10:52 AM, Barry Warsaw wrote:
Probably the best thing to do (on *nix at least) is, if the path is absolute,
use the given string verbatim. If the path is relative, search for the given
executable on $PATH and use the first one found. If nothing is found, use
what's given
On 17 February 2015 at 21:40, Barry Warsaw ba...@python.org wrote:
OTOH, I think it *would* be useful to have this built into Python. We almost
have too many choices, and may people I've talked to lately (including
experienced Pythonistas) have trouble choosing the right tool. But that can
Blaxton writes:
I am using the spec file that comes with Python source code which
downloaded from python.org website
Ah, sorry, I didn't realize that. My advice still stands; while there
are Red Hat/Fedora/other-RPM-based distro workers here, I don't know
if any of them actually have
- Original Message -
Blaxton writes:
I am using the spec file that comes with Python source code which
downloaded from python.org website
Ah, sorry, I didn't realize that. My advice still stands; while there
are Red Hat/Fedora/other-RPM-based distro workers here, I don't know
On Feb 17, 2015, at 09:52 PM, Paul Moore wrote:
I see no problem with either having zipapp develop into a much
fuller-featured solution, or having an externally developed tool
brought into the stdlib and replacing zipapp. I just don't think
there's anything mature enough for that role out there
On Feb 17, 2015, at 09:45 PM, Paul Moore wrote:
If Python zip applications got the ability to include binary extensions, they
would *definitely* not be portable (we don't want to go down the route of
wheel-like compatibility tags for an application file format).
Agreed!
Currently, I'm trying to
On Sun, Feb 15, 2015 at 1:45 PM, Serhiy Storchaka storch...@gmail.com wrote:
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
28 matches
Mail list logo
