Re: Python, Be Bold!

[Chris Angelico]

On Thu, Jan 2, 2020 at 6:20 PM Abdur-Rahmaan Janhangeer
 wrote:
>
> if not self-updating, at least the ability to update
>

That's a package manager's job.

$ sudo apt update
$ sudo apt upgrade

Job done. The wheel does not need to be reinvented.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

i wonder who uses windows

On Thu, 2 Jan 2020, 12:38 Chris Angelico,  wrote:

> On Thu, Jan 2, 2020 at 6:20 PM Abdur-Rahmaan Janhangeer
>  wrote:
> >
> > if not self-updating, at least the ability to update
> >
>
> That's a package manager's job.
>
> $ sudo apt update
> $ sudo apt upgrade
>
> Job done. The wheel does not need to be reinvented.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Michael Torrie]

On 1/2/20 2:41 AM, Abdur-Rahmaan Janhangeer wrote:
> i wonder who uses windows

If this kind of thing is important to a user , what you propose would
probably be the responsibility of the entity that is producing a Python
distribution, such as Anaconda.  Usually in such cases these
distributions are not targeted at developers per se, but scientific
users who write small programs to solve particular problems.  And it may
be appropriate in that case.

Python is just a language specification and some tools (including a
reference implementation of the interpreter and standard library). It's
not an IDE and it's not a software distribution.  I know that other
languages have turned themselves into such things.  Particularly node.js
with npm, and that has been a real mess on occasion.  I haven't heard
anything about Java being like this, though.  I guess Visual Studio has
added a package manager.  However that's separate from the language
itself (C#, C++, etc).

How would you determine what should be updated? The core libraries are
already updated with the interpreter version, and have some dependency
on the interpreter version.  You seem to be suggesting that third-party
libraries from PyPi or other places should automatically update, and
that seems like a bad idea to me, as they each operate under their own
standards of API compatibility, quality, and so forth.  All you have to
do is look at the mess that is npm in node.js to see what this idea has
some real problems if you were to update everything in one swoop in a
semi-automated fashion.

Personally if I were working on a large Python project that I wanted to
release to clients involving a few third-party packages, I would not be
interested in any sort of automatic updating.  Without testing, such
automatic updates could easily break my program.  And the last thing I'd
want is a client or customer to be updating dependencies on his own!

How would you address these issues?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Source code organisation

[Terry Reedy]

On 1/2/2020 2:46 AM, Cameron Simpson wrote:

Inline code under the if...__main__ stuff cannot be called as a 
function;


Which makes it difficult to test app startup.

I usually consider the main() function a reusable component. 


Which, if called (at least optionally) with a list of string arguments 
(sys.argv) as Cameron suggested, makes it easy to test with various 
lists of strings.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

Oh auto-3rd party modules is a mess. Suggesting updating only the
interpreter. We can have a pre-scan which warns the user that upgrading
will make the following packages no longer compatible. But that's one aim
of venvs i think, is to confine packages to projects, not to the
interpreter.

No java does not have such a feature, it's a suggestion that's unrelated to
Java.

For distributing to clients, you don't rely on the user interpreter for
packages. As far as I know, some companies select let's say version 1.0.5
of a library, and ... they keep it internal, they might modify it as
desired. It becomes a home pet. They distribute this version with their
project. Even if the library is at 2. they use the modified 1. for
increased stability. That's one extreme.

Having a sort of .jar running with the system interpreter concerns syntax
and enforced standards.

To further ease dist, much work is required to be done on the project
format itself. If i remember well, a PEP proposed to install 3rd party
packages in a folder in the project, which might further enhance the
process.

Having a Python-specific executable allows you to go to whatever length you
desire to make project bundling an easy task. The other effort is to get
your interpreter/VM running on as many hardwares as possible. This includes
the effort to make it lighter, faster etc. It might entails the complete
removal of 3rd party packaging interpreter side or not using it when
running the specific executable.

I believe Python should be able to run on any device. I believe that my
Python code should go everywhere. It pains me to see a project not choosing
Python as an add-on scripting language due to the size of the interpreter
or things of the sort.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

Coincidentally, one day before i posted this approach, a user posted on
Idle-dev:

[Idle-dev] Wishlist: Make executables + startup option

which proposes the idea of adding an option to generate a single executable
from Idle. It reflects the profound desire of the community to distribute
their apps professionally.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Source code organisation

[DL Neil via Python-list]

On 3/01/20 7:36 AM, Terry Reedy wrote:

On 1/2/2020 2:46 AM, Cameron Simpson wrote:


Inline code under the if...__main__ stuff cannot be called as a function;


Which makes it difficult to test app startup.

I usually consider the main() function a reusable component. 


Which, if called (at least optionally) with a list of string arguments 
(sys.argv) as Cameron suggested, makes it easy to test with various 
lists of strings.



NB I agree with suggestion that 'important stuff' is better placed at 
'top' of source-code. Preceding comment assumes that main() is to be a 
word/name which catches the eye and has 'importance' attached. However, 
the Python idiom is "if __name__ == '__main__'" and (paradoxically?) 
that usually goes at the 'bottom'.


I think we've previously discussed if __name__ == '__main__' and/vs main().


Continuing the discussion, above:-


def start_up( args ): etc

def do_it( args ): etc

def close_down( args ): etc

if __name__ == '__main__':
   start_up( sys.argv )
   do_it( etc )
   close_down( etc )


1. app startup remains test-able
2. each component is reusable
3. sys.argv may be passed with all flexibility
4. separation of concerns, etc, observed

NB above for casual illustration only - if start_up() is more than 
trivial, seems likely that others would be better implemented as context 
manager, etc, etc...

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 6:39 AM Abdur-Rahmaan Janhangeer
 wrote:
> Having a Python-specific executable allows you to go to whatever length you
> desire to make project bundling an easy task. The other effort is to get
> your interpreter/VM running on as many hardwares as possible. This includes
> the effort to make it lighter, faster etc. It might entails the complete
> removal of 3rd party packaging interpreter side or not using it when
> running the specific executable.
>
> I believe Python should be able to run on any device. I believe that my
> Python code should go everywhere. It pains me to see a project not choosing
> Python as an add-on scripting language due to the size of the interpreter
> or things of the sort.

What do you mean by "Python-specific executable"?

Your Python code can go anywhere if you package it up in, say, a .deb
or .rpm, and then just depend on a Python interpreter of appropriate
version. You can allow your users to manage their own updates so long
as it's within the dependency range you have chosen to support. I
don't understand how "run on any device" relates to "automatically
update the Python interpreter", but it's still a solved problem: *use
a package manager*.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 00:14 Chris Angelico,  wrote:

>
> What do you mean by "Python-specific executable"?
>

a Python equivalent of .jar


> Your Python code can go anywhere if you package it up in, say, a .deb
> or .rpm,


Not everybody uses Linux

I
> don't understand how "run on any device" relates to "automatically
> update the Python interpreter",


Two unrelated suggestions

but it's still a solved problem: *use
> a package manager*.
>

Single-file executables are slick. End-users want to only use the app.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 7:22 AM Abdur-Rahmaan Janhangeer
 wrote:
>
> On Fri, 3 Jan 2020, 00:14 Chris Angelico,  wrote:
>>
>>
>> What do you mean by "Python-specific executable"?
>
>
> a Python equivalent of .jar

A jar is just an archive of Java class files. It's approximately
equivalent to a zip file of .pyc files. You can't run a .jar file
without a Java interpreter.

>> Your Python code can go anywhere if you package it up in, say, a .deb
>> or .rpm,
>
> Not everybody uses Linux

No, but there are package managers for Windows and Mac too. (I don't
think there's any first-party package manager for Macs, but there are
some very popular third-party ones eg Homebrew.)

>> I
>> don't understand how "run on any device" relates to "automatically
>> update the Python interpreter",
>
>
> Two unrelated suggestions
>
>> but it's still a solved problem: *use
>> a package manager*.
>
>
> Single-file executables are slick. End-users want to only use the app.

And that's the problem: the single-file executable requires you to
bundle everything, update it yourself, and duplicate all the code
everywhere.

Using a package manager means you have ONE copy of the Python
interpreter, and all your scripts depend on it. If you update that
interpreter, ALL scripts benefit from the update. This is a solved
problem.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 00:33 Chris Angelico,  wrote:

> A jar is just an archive of Java class files. It's approximately
> equivalent to a zip file of .pyc files.
>

Exactly the idea, that's why i said zipapp might be a good candidate

No, but there are package managers for Windows and Mac too. (I don't
> think there's any first-party package manager for Macs, but there are
> some very popular third-party ones eg Homebrew.)
>
> ...
>
> And that's the problem: the single-file executable requires you to
> bundle everything, update it yourself, and duplicate all the code
> everywhere.
>
> Using a package manager means you have ONE copy of the Python
> interpreter, and all your scripts depend on it. If you update that
> interpreter, ALL scripts benefit from the update. This is a solved
> problem.
>

I am not proposing native executables, but a .jar like executable. The term
executable refers to one click run.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 7:42 AM Abdur-Rahmaan Janhangeer
 wrote:
>
>
>
> On Fri, 3 Jan 2020, 00:33 Chris Angelico,  wrote:
>>
>> A jar is just an archive of Java class files. It's approximately
>> equivalent to a zip file of .pyc files.
>
>
> Exactly the idea, that's why i said zipapp might be a good candidate
>
>> No, but there are package managers for Windows and Mac too. (I don't
>> think there's any first-party package manager for Macs, but there are
>> some very popular third-party ones eg Homebrew.)
>>
>> ...
>>
>> And that's the problem: the single-file executable requires you to
>> bundle everything, update it yourself, and duplicate all the code
>> everywhere.
>>
>> Using a package manager means you have ONE copy of the Python
>> interpreter, and all your scripts depend on it. If you update that
>> interpreter, ALL scripts benefit from the update. This is a solved
>> problem.
>
>
> I am not proposing native executables, but a .jar like executable. The term 
> executable refers to one click run.
>

Then we already have this. On Windows, set your file associations
appropriately. On Unix-like platforms, have a shebang at the start,
and chmod it +x. Example:

https://github.com/Rosuav/shed/blob/master/steamguard

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

>
> Then we already have this. On Windows, set your file associations
> appropriately. On Unix-like platforms, have a shebang at the start,
> and chmod it +x.
>

Not proposing only executable but single file executable.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Michael Torrie]

On 1/2/20 1:33 PM, Chris Angelico wrote:
> Using a package manager means you have ONE copy of the Python
> interpreter, and all your scripts depend on it. If you update that
> interpreter, ALL scripts benefit from the update. This is a solved
> problem.

Except that it's not actually a solved problem.  We thought it was but
then found the limitations.  Linux distros are actually moving away from
a pure packager dependency model, especially for applications. System
components, yes. Makes a lot of sense. Makes less sense for user-facing
things.  That's why there's a lot of movement going with regards to
solutions like flatpak, snap, and even AppImage.  RPMs and debs are
never going to go away, but they do have limitations for the kind of
thing the OP is talking about.  Right now in Fedora land, a very
appropriate way to bundle a python application is in a flatpak, bundled
with the appropriate versions of Python and the libraries you depend on.
 More and more apps on Ubuntu are being delivered via snaps too.
Especially ones that move fast like Firefox, or even LibreOffice.

I use several apps that are flatpaks because my distro is old and stable
(CentOS 7) and doesn't have a lot of the dependent shiny libs modern
apps require. Flatpak lets me run them while keeping the core system
very conservative and stable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 7:54 AM Abdur-Rahmaan Janhangeer
 wrote:
>>
>> Then we already have this. On Windows, set your file associations
>> appropriately. On Unix-like platforms, have a shebang at the start,
>> and chmod it +x.
>
>
> Not proposing only executable but single file executable.
>

I linked you to a single file executable of mine. It makes use of...
oh hey, the system package manager. See? It works.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Michael Torrie]

On 1/2/20 1:42 PM, Abdur-Rahmaan Janhangeer wrote:
> I am not proposing native executables, but a .jar like executable. The term
> executable refers to one click run.

But a jar file is not executable on Windows and never has been.  You
can't go to the cmd.exe window and type "myprogram.jar."  Maybe it can
be opened with a file association linking it to a Java runtime
executable. But it's certainly not a Windows executable.  And I've never
ever seen anyone launch a java jar file by double clicking on it.  Most
people provide .bat files to start it, or a lnk file that contains the
necessary java flags.

As Chris said with file associations you can already double-click on a
py file (or pyw without a console window by convention).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 7:58 AM Michael Torrie  wrote:
>
> On 1/2/20 1:33 PM, Chris Angelico wrote:
> > Using a package manager means you have ONE copy of the Python
> > interpreter, and all your scripts depend on it. If you update that
> > interpreter, ALL scripts benefit from the update. This is a solved
> > problem.
>
> Except that it's not actually a solved problem.  We thought it was but
> then found the limitations.  Linux distros are actually moving away from
> a pure packager dependency model, especially for applications. System
> components, yes. Makes a lot of sense. Makes less sense for user-facing
> things.  That's why there's a lot of movement going with regards to
> solutions like flatpak, snap, and even AppImage.  RPMs and debs are
> never going to go away, but they do have limitations for the kind of
> thing the OP is talking about.

They are still FAR better than trying to create a single bloated
executable that contains everything and magically knows how and when
to update itself. If you're going to use snaps etc, you do so with
full control of what you're bundling together, rather than hoping that
the publisher of the program will (a) bundle the correct versions, and
(b) keep them up-to-date.

I'm not seeing any Linux distro moving towards a model where every
program author has to include the entire binary and make 32-bit and
64-bit versions available, etc, etc, etc, as is often seen elsewhere.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 00:58 Chris Angelico,  wrote:

>
> I linked you to a single file executable of mine. It makes use of...
> oh hey, the system package manager. See? It works.
>

I don't understand this one

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 01:01 Michael Torrie,  wrote:

>
> But a jar file is not executable on Windows and never has been.

 

Maybe it can
> be opened with a file association linking it to a Java runtime
> executable.
>

That's it. See UMLet's distribution mode for example

As Chris said with file associations you can already double-click on a
> py file (or pyw without a console window by convention).
>

But single file are better suited for distribution.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 01:05 Chris Angelico,  wrote:

>
> They are still FAR better than trying to create a single bloated
> executable that contains everything and magically knows how and when
> to update itself.
>

Proposing to freeze things. You distribute a version of the program. The
single file (not using the word executable as it seemingly leads to
confusions) is given with the assurance that the only thing you need is an
interpreter for it to work.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Michael Torrie]

On 1/2/20 2:11 PM, Abdur-Rahmaan Janhangeer wrote:
> But single file are better suited for distribution.

Maybe.  Most windows applications are distributed with installers.  I've
made several bundles over the years with Nullsoft's installer builder.
That's how commercial companies, including those that use Python,
distribute their applications.  Here's a popular open source application
build on Python, and it's installer (a single msi file):
https://calibre-ebook.com/download_windows

I haven't seen very many single-exe windows applications ever.

Anyway we can argue forever about what ought to be.  But until someone
does it and proves that it's important, it's not going to happen.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 8:17 AM Abdur-Rahmaan Janhangeer
 wrote:
>
>
>
> On Fri, 3 Jan 2020, 01:05 Chris Angelico,  wrote:
>>
>>
>> They are still FAR better than trying to create a single bloated
>> executable that contains everything and magically knows how and when
>> to update itself.
>
>
> Proposing to freeze things. You distribute a version of the program. The 
> single file (not using the word executable as it seemingly leads to 
> confusions) is given with the assurance that the only thing you need is an 
> interpreter for it to work.
>

Wait, so as well as the single file, you ALSO need a Python
interpreter? Then what's the point? Why not just distribute a .py
file?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Grant Edwards]

On 2020-01-02, Michael Torrie  wrote:
> On 1/2/20 2:11 PM, Abdur-Rahmaan Janhangeer wrote:
>> But single file are better suited for distribution.
>
> Maybe.  Most windows applications are distributed with installers.

Definitely.

Single file executables aren't really "a thing" on Windows.

> [...]
> I haven't seen very many single-exe windows applications ever.

Putty is still made available as a single file executable.  But, it's
the only one I've seen for a couple decades.

AFAICT, 99.999% of Windows apps are distributed as an .msi file or as
a self-extracting installer (e.g. foobar-1.2.3-setup.exe) file.  If
that's what you want to do with your python app, then you can use
cx_freeze et alia.  Packagining something for wide distribution can be
a bit a fiddly to get right: you need to know what you're doing, and
you need to do a lot of testing.

But that's true regardless of OS or language.

-- 
Grant Edwards   grant.b.edwardsYow! Are you the
  at   self-frying president?
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Barry Scott]

> On 2 Jan 2020, at 21:17, Abdur-Rahmaan Janhangeer  
> wrote:
> 
> On Fri, 3 Jan 2020, 01:05 Chris Angelico,  wrote:
> 
>> 
>> They are still FAR better than trying to create a single bloated
>> executable that contains everything and magically knows how and when
>> to update itself.
>> 
> 
> Proposing to freeze things. You distribute a version of the program. The
> single file (not using the word executable as it seemingly leads to
> confusions) is given with the assurance that the only thing you need is an
> interpreter for it to work.

Expect for trivial programs you cannot distribute a single file python exe for 
windows.
As you found zipapp is not a solution.

Many stdlib modules use DLL's on Windows and you cannot run a DLL from
inside a zip file.

As soon as you have a GUI interface you have to install lots of DLLs and
the C++ runtime. The only easy way to support users is by using a
windows installer. I use inno installer for windows which is a very powerful
tool, https://www.jrsoftware.org/isinfo.php 
. And I create the windows app
with https://pypi.org/project/win-app-packager/ 
 (I'm the author).

The situation for the Mac requires you to create a .app bundle.
The way these are distributed is as a compressed .dmg file.
I use py2app and dmgbuild to get the job done on macOS.

As Chris noted its easier on Linux systems. You can make a package
(.deb or .rpm) that uses the already packaged python code and libraries.

There are excellent solutions that have existed for many years to
package python apps for Windows, macOS and Linux. On Windows
and macOS it is necessary to install python, you just bundle it inside the
app.

I support two apps on Windows, macOS and unix that does exactly this.
http://barrys-emacs.org  and 
http://http://scm-workbench.barrys-emacs.org/ 


For command line tools pip knows how to install a .exe for Windows that
runs the tool. On macOS and linux its creates a small boot strap script.

As an example see my https://pypi.org/project/colour-text/ 
 project
that installs the colour-print command.

All the code for the above is open source and you can read the code
used to build the install kits.

Barry



> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Greg Ewing]

It looks like what the OP is after already exists:

https://docs.python.org/3/library/zipapp.html

"This module provides tools to manage the creation of zip files 
containing Python code, which can be executed directly by the Python 
interpreter."


--
Greg

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[mm0fmf]

On 02/01/2020 09:41, Abdur-Rahmaan Janhangeer wrote:

i wonder who uses windows



I do. The man pays me well to write software for Windows and Linux and I 
don't care which . It's just an OS, write the code to do what the spec 
says. Not a difficult concept really.


apt-get works fine for me on Linux. On Windows I currently have Python 
3.7.3 which comes with a nice installer and uninstalls via the OS apps 
management. (i.e. it has an uninstaller somewhere).



--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 03:25 Greg Ewing,  wrote:

> It looks like what the OP is after already exists:
>
> https://docs.python.org/3/library/zipapp.html
>
> "This module provides tools to manage the creation of zip files
> containing Python code, which can be executed directly by the Python
> interpreter."
>

Oh my, you did not read from the begining. Please do so. I would really
like to rewrite what i said but it's too long.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 03:35 mm0fmf,  wrote:

> On 02/01/2020 09:41, Abdur-Rahmaan Janhangeer wrote:
> > i wonder who uses windows
> >
>
> I do. The man pays me well to write software for Windows and Linux and I
> don't care which . It's just an OS, write the code to do what the spec
> says. Not a difficult concept really.
>

Was a pointing out that people use windows also.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 01:43 Chris Angelico,  wrote:

>
> Wait, so as well as the single file, you ALSO need a Python
> interpreter? Then what's the point? Why not just distribute a .py
> file?
>

Well let's say a Flask, Django or PyQt app, a single file is not really
feasible.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 01:43 Michael Torrie,  wrote:

> On 1/2/20 2:11 PM, Abdur-Rahmaan Janhangeer wrote:
> > But single file are better suited for distribution.
>
> Maybe.  Most windows applications are distributed with installers.  I've
> made several bundles over the years with Nullsoft's installer builder.
> That's how commercial companies, including those that use Python,
> distribute their applications.  Here's a popular open source application
> build on Python, and it's installer (a single msi file):
> https://calibre-ebook.com/download_windows
>
> I haven't seen very many single-exe windows applications ever.
>

This proposal is not about native executables

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 02:49 Grant Edwards,  wrote:

>
> Definitely.
>
> Single file executables aren't really "a thing" on Windows.
>


This proposal is about a .jar like file executable, not native executables

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

One of the advantages of single "executable"s is the abstraction of
details. You don't want users to see what you included. It's an attempt at
hiding away details for aesthetic purposes. The second reason is
compression. You get a lighter program. The third reason is to be as
reverse-engineer resistant as possible.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 02:50 Barry Scott,  wrote:

> Expect for trivial programs you cannot distribute a single file python exe
> for windows.
>

You can, PyInstaller does it. You can have folder-based or single file apps

As you found zipapp is not a solution.
>

 Zipapp is a good candidate. Proposing to improve it


> Many stdlib modules use DLL's on Windows and you cannot run a DLL from
> inside a zip file.
>

PyInstaller's -F mode does it well

But, this proposal is not about native executables. It's about a .jar like
executable. As a python-specific 'executable', os is not a problem unless
of course you are using like curses on windows
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Bob van der Poel]

Oh, now we get the rational. No thank you! Enough of the world is hidden
away as it is.

On Thu, Jan 2, 2020 at 7:22 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> One of the advantages of single "executable"s is the abstraction of
> details. You don't want users to see what you included. It's an attempt at
> hiding away details for aesthetic purposes. The second reason is
> compression. You get a lighter program. The third reason is to be as
> reverse-engineer resistant as possible.
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 06:33 Bob van der Poel,  wrote:

> Oh, now we get the rational. No thank you! Enough of the world is hidden
> away as it is.
>

Zipapp was introduced for a reason, .jar for a reason. This proposal also
adds in the ability of the interpreter to notify of new Python releases.

>
-- 
https://mail.python.org/mailman/listinfo/python-list