On Sun, 5 Jan 2020, 14:38 Marco Sulla, <
mail.python@marco.sulla.e4ward.com> wrote:
>
> Sorry, I do not understand.
> Probably do you mean: I install all the wheels in a machine identical
> to the target I want (maybe using a VM, I don't know if Python support
> cross-compiling). Then I copy the folders of the modules inside my
> app?
>
> The problem is: who will maintain the pre-compiled versions of the
> modules for every OSes? As a programmer, I can assure you I'm not
> really slightly interested to do this work at all :D
>
Nor me, a bad idea, this part is open for discussion.
IMHO the most simple solution is that Python ships, together the
> installer of the interpreter, a C compiler for systems, like Windows,
> where such compiler is not pre-installed. Maybe gcc or Clang. If the
> user wants to use its installer, no problem, (s)he can customize it.
>
> This way you can create a sort of python installer that is nothing
> more that a zip file with the source code of the app, the wheels of
> the dependencies and a setup.py. Where the zip is opened by python, it
> should execute the setup.py, that will create the venv, install the
> app and the wheels. And since Python ships a beautiful C compiler, the
> wheels will be installed without problems (in the best of the
> worlds...)
>
This part is open to discussions. It should be under: Proposed changes to
the interpreter part
> Do you have the link of the PEP you cited?
>
Must look for it, will be a long hunt apparently
The end user it's not interested to have the most updated Python in
> the world.
As you said down below, programs do. The adoption of 3.7 was amazing, i've
seen libs use f strings as though it was an old buddy. People are
interested to build programs using new features available but that's
according to me is bad practise as you always have people lagging behind.
But on the other hand security fixes interpreter side might be a good
upgrade inventive.
The end user probably does not even _know_ what is Python.
>
That's what the Python, Be Bold approach suggests, to make end-users more
and more aware of what a Python distribution is. It should not be a shame
for devs to introduce end-users to a Python installation on their system.
For example, what happens if an user tries to use an executable jar
> than needs a more updated version of java than the one that is
> installed on the user machine? Well, if it's well written, it's the
> program itself that gives him / her an alert: "You need Java version
> Z".
That's a nice idea, but if on interpreter side, might be easier unless
in-built alert mechanism when executing the archive.
The user will snort, and finally will search on Google the Java
> version (s)he needs.No auto update.
No ... auto-update is a bad idea, third time saying that on this thread ^^_
Proposing instead the ability to update not auto-update
--
https://mail.python.org/mailman/listinfo/python-list
