[Python-ideas] Re: Enhancing Zipapp

[Stephen J. Turnbull]

Barry Scott writes:

 > Also beware that zip file format does not include the encoding of
 > the files that are in the zip file.

The most recent zipfile format, which is now a decade or so old, does
specify the encoding, for values of 0 = ASCII, 1 = UTF-8.[1]

 > This means that for practical purposes only ASCII filenames are
 > portable across systems. Is this limitation a problem for this
 > proposal?

As far as I know, with the exception of a few Japanese bureaucrats,
everybody uses zip implementations that handle non-ASCII properly.
InfoZip is one such that is portable, although I don't recall how it
handles filesystems with non-Unicode file name encodings.

>From the point of view of this proposal, just require that filename
encodings be properly specified, and provide an option to use the
appropriate codec.  This isn't too hard.  The main thing to rule out
is multiple encodings in one file system (yes, I've seen it, but not
recently, thank the powers).

This could even be handled (on POSIX filesystems) with an auxiliary
utility that converts whatever-encoded filenames to UTF-8 (could be a
symlink tree).  Then you can just require a UTF-8 filesystem
throughout the zipapp handling system.  Only remaining question in my
mind would be backward compatibility with any existing zipapp specs
(which I have no idea about, but if I were participating in
implementation I'd be sure to check).


Footnotes: 
[1]  Or maybe it's 0 = ISO-8859-1, 1 = UTF-8.  Sorry, don't have a
copy of the spec handy.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I7AE3GYD7T57NEMVGFWIEWC2DQZ6MMPN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a PyObject_VaCallFunction to C API??

[hrfudan]

Thanks for the suggestion. I haven't looked at PyCXX yet. I'll definitely check 
it out sometime. In light of your and other people's replies, I probably will 
postpone the development till I think it through, especially after another day 
of trying and failing. 

I do have one question for you, and for anyone who is kind enough to read this: 
how can I know if a PyObject_Call(...) or PyObject_GetAttr(...) returns a new 
ref or a borrowed ref? I read online ( Python 3 ) that they are returning new 
references. But does everyone comply with it? If so, it seems safe for me to 
capture the return PyObject* into a wrapper class that automatically 
Py_DECREF() upon destruction. But if not, what documentations should I refer to 
for the behavior of a specific python module ( for example, matplotlib )?

This is the first time I ever checked out the Python C API, I guess I'm in need 
of some conventions here. Your input is much appreciated.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CFYYKFBEBEVOPDQPKEGNF7XDDL5AZEG5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a PyObject_VaCallFunction to C API??

[Rui Hu]

I see! That definitely helps. What about a call to 
PyObject_CallMethodObjArgs()? Under the hood, is it really the same as a first 
call to PyObject_GetAttr() to get an attribute which is followed by another 
call to PyObject_Call()? I read Objects/call.c and seems to me this is the 
case. I'm asking because with Py_VaBuildValue() the only to simulate 
Py_CallMethodObjArgs() is the two-way call described above.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HFVMU4WX2QK3RIIAENMFFCOYLFHNDBZK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a PyObject_VaCallFunction to C API??

[Rui Hu]

I fully agree that the workflow should be Python to C. Thanks for the suggested 
tools. I heard about Cython almost the same time I heard about Python. I will 
look at it for wisdom! 

My situation is exactly the "Unless" one you mentioned. Since the dataset can 
be huge, multiple computer nodes will be needed to crunch the numbers and form 
something ( hopefully much smaller ) to be visualized in Python ( via 
matplotlib ). I could save a dataset ( say in hdf5 ) after all the computers 
finished calculation, and read it into Python. But I was thinking since the 
processed dataset is already in the memory, maybe a direct call to Python for 
matplotlib functionality could be achieved?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6BIDYUFUVJKK4LU2IWDQIE37QYBDIFMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a PyObject_VaCallFunction to C API??

[MRAB]

On 2020-01-07 20:22, hrfu...@gmail.com wrote:

Thanks for the suggestion. I haven't looked at PyCXX yet. I'll definitely check 
it out sometime. In light of your and other people's replies, I probably will 
postpone the development till I think it through, especially after another day 
of trying and failing.

I do have one question for you, and for anyone who is kind enough to read this: 
how can I know if a PyObject_Call(...) or PyObject_GetAttr(...) returns a new 
ref or a borrowed ref? I read online ( Python 3 ) that they are returning new 
references. But does everyone comply with it? If so, it seems safe for me to 
capture the return PyObject* into a wrapper class that automatically 
Py_DECREF() upon destruction. But if not, what documentations should I refer to 
for the behavior of a specific python module ( for example, matplotlib )?

This is the first time I ever checked out the Python C API, I guess I'm in need 
of some conventions here. Your input is much appreciated.


The docs will say if it returns a new reference or a borrowed reference.

The general rule is that those functions that store an object in a 
container, e.g. PyList_Append, will incref in order to retain the 
object, but there are a few, such as PyList_SetItem, which don't incref, 
but instead "steal" the reference.


A careful read of the docs is always advised. There's an occasional 
exception!

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JRFKJX3CSBJPORRZ7ODSF4C56VG33QLO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Brett Cannon]

Thanks for the ideas, Abdur-Rahmaan! Some feedback below.

On Mon, Jan 6, 2020 at 11:35 AM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Note: draft simplified
>
> Abstract
> ==
>
> This extracts aims at proposing enhancements to the generated zipapp
> executable
>
> Rationale
> ===
>
> One area where there remains some difficulty in Python is packaging for
> end-user consumption. To that effect either the code is distributed in pure
> Python form with installers [1] or native executables are built for each
> target
> Os [2]. Currently by default, Python does not provide such utilities. This
> pro-
> posal aims at finalising a Python-specific archive as the default VM exec-
> utable built on zipapp.
>
> In simple terms, it proposes to enhance zipapp from plain archive to
> app-level
> archive.
>
> Advantages of archives
> ==
>
> 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 [3]
>
> You can use archives for tasks such as lossless data compression,
> archiving,
> decompression, and archive unpacking. [4] Adding capabilities like digital
> signing is used to verify integrity and authenticity.
>
> Zip archives as apps
> 
>
> If we are to treat zip archives as app, here are some recommended features
>
> - [x] Main entry point
>
> A main entry point specifies which file to launch. Zipapp already solves
> this
> problem by either having a __main__.py [5] or specifying the entry point
> at the
> commandline ENTRYPOINT_MODULE:ENTRYPOINT_FUNCTION [6]
>
> - [  ] App info file
>
> An info file can have info such as author name, archiving date, company
> name
> etc.
>

This would be a packaging detail so not something to be specified in the
stdlib.


>
> - [  ] Signing mechanism
>
> Mechanisms can be added to detect the integrity of the app. App hash can
> be
> used to check if the app has been modified and per-file hash can be used
> to
> detect what part has been modified. This can be further enhanced if needed.
>
> - [  ] Protecting meta data
>
> Metadata are not protected by basic signing. There existing ways to protect
> metadata and beyond [7]
>

This can be tricky because people want signing in specific ways that vary
from OS to OS, case by case. So unless there's a built-in signing mechanism
the flexibility required here is huge.


>
>  - [x] Pure-Python 3rd party package bundling
>
> In Python, as long as the 3rd party packages are pure-python packages, we
> can bundle and use them [6]. The user can maybe just include a
> requirements.txt
>
> - [  ] C-based 3rd party packages
>
> Zipapp by default was not meant to include packages at all.
>
> << The executable zip format is specifically designed for standalone use,
> without needing to be installed. They are in effect a multi-file version
> of a
> standalone Python script >>
>
> Though the previous point shows that this can be done. Now remains the
> issue of C-based packages. Distributing wheels might be the answer [8].
> A zip archive is supposed to be standalone. A possible  solution might be
> to
> include wheels and the wheels are installed in a site-packages folder.
>
> When running such an app, the interpreter will check first if the
> app-specific
> site-packages folder is empty, if not, install the wheels. This provides
> package-
> freezing ability. The only downside is longer first-run time.
>

Install the wheels where? You can't do that globally. And you also have to
worry about the security of doing the install implicitly. And now the user
suddenly has stuff on their file system they may not have asked for as a
side-effect which may upset some people who are tight on disk space
(remember that Python runs on some low-powered machines).

-Brett


>
> Only specifying packages to be installed is not an option as if you really
> want
> stand-alone apps, using the internet etc defeats the purpose.
>
> FAQ
> 
>
> Why not a package manager?
> ---
> The zipapp pep was introduced for a reason, for easing the running of
> archives.
> Maybe the package manager idea came from listening to people talking about
> packaging and pex and comparing it with package-managers like homebrew
> and concluded that pex and hence zipapp is not worth it and people would
> better off not complicate their lives with some zip utility.
>
> This proposal is not solving any problem at all
> --
> This proposal aims at enhancing zipapp. Zipapp solved the problem. Zipapp
> had an aim. This proposal aims at helping zipapp better accompplish it's
> aim.
>
>
> References
>
> [1] https://pynsist.readthedocs.io/en/latest/
>
> [2] https://www.pyinstaller.org
>
> [3] https://www.python.org/dev/peps/pep-0441/
>
> [4]
> https://docs.oracle.com/javase/tutorial/deployment/jar/basicsindex.html
>
> [5] https://docs

[Python-ideas] Re: Add a PyObject_VaCallFunction to C API??

[MRAB]

On 2020-01-07 20:37, Rui Hu wrote:

I see! That definitely helps. What about a call to 
PyObject_CallMethodObjArgs()? Under the hood, is it really the same as a first 
call to PyObject_GetAttr() to get an attribute which is followed by another 
call to PyObject_Call()? I read Objects/call.c and seems to me this is the 
case. I'm asking because with Py_VaBuildValue() the only to simulate 
Py_CallMethodObjArgs() is the two-way call described above.

It returns a new reference because it's returning a result, which might 
be a newly-created object.


Consider, say, PyList_GetItem. The object it returns is in the list, so 
doing an incref would be wasteful (you're not expecting the object to 
disappear unexpectedly). It's a borrowed reference, and that's good enough.


Now consider PyUnicode_Substring. The result is a substring, so some 
copying must take place. A new string is created and returned. It 
returns a new reference.


Except that it doesn't always create a new string.

If the substring happens to include all of the characters, there's no 
need to make a copy, because strings are immutable. It'll just do an 
incref and return the original string, and your code will be none the wiser.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GJWEAN6LLTCDGS4S5SP3PL3C24KCBJER/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Barry]

> On 7 Jan 2020, at 02:40, Christopher Barker  wrote:
> 
> 
> I’m a bit unclear on how far this goes: is it just a bit more specific with 
> more meta-data standards?
> 
> Or are you aiming for something that will run without a Python install? 
> 
> Other issues:
> 
> Are you aiming for a bundle that can run on multiple platforms? If so, then 
> it’ll have to have a way to bundle multiple compiled extensions and select 
> the right ones at runtime.
> 
> If this Is essentially just zipapp with the ability to bundle dependencies, 
> then you could probably just do some sys.path hackery.
> 
> In any case, thus seems like something you could implement, and then see if 
> people find it useful.
> 
> BTW- I’m pretty sure we could simply specify that filenames are utf-8 and 
> we’d be good to go.

Have a look at this write up about the horror that is zip file name handling.

https://marcosc.com/2008/12/zip-files-and-encoding-i-hate-you/

This has been a pain point at work.

Barry

> 
> -CHB
> 
> 
> 
> 
> 
>> On Mon, Jan 6, 2020 at 5:50 PM Abdur-Rahmaan Janhangeer 
>>  wrote:
>> 
>> 
>>> On Tue, 7 Jan 2020, 01:57 Barry Scott,  wrote:
>>> 
>>> 
>>> Please cover the pro's and con's of the alernatives that have been raised 
>>> as comments
>>> on this idea, as is usually done for a PEP style document.
>> 
>> 
>> Thanks, i don't have much experience writing peps and
>> if i don't bug you may i ask what "alternatives" refer to?
>> 
>>> Also beware that zip file format does not include the encoding of the files 
>>> that are in the
>>> zip file.
>> 
>> 
>> For the encoding of the contents, well since we are
>> packaging python code files, it's handling will be the same
>> as handling outside the zip file. It's handling is the
>> same as how zipapp handles things.
>> 
>>> This means that for practical purposes only ASCII filenames are portable 
>>> across
>>> systems. Is this limitation a problem for this proposal?
>> 
>> 
>> If we are talking about filenames, then i guess
>> ascii filenames are the way to go as you'd 
>> unnecessarily break things otherwise.
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/python-ideas@python.org/message/RVGFMDP3PG6TXFQGH7ISRLYM4FS5CO64/
>> Code of Conduct: http://python.org/psf/codeofconduct/
> -- 
> Christopher Barker, PhD
> 
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4ZU5L7HSYJNAXWQ437A5VJFV7NACQXIR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Barry]

> On 7 Jan 2020, at 01:48, Abdur-Rahmaan Janhangeer  
> wrote:
> 
> 
> 
> 
>> On Tue, 7 Jan 2020, 01:57 Barry Scott,  wrote:
>> 
>> 
>> Please cover the pro's and con's of the alernatives that have been raised as 
>> comments
>> on this idea, as is usually done for a PEP style document.
> 
> 
> Thanks, i don't have much experience writing peps and
> if i don't bug you may i ask what "alternatives" refer to?

You are offing up a competitor against python wheels, Py2app, py2exe etc 
packagers.
Explain the benefits and weaknesses compared to the existing alternatives.

You might want to look at pex that is mentioned in the pep you refer to.
The other mentioned app has seen no update sine 2013.

> 
>> Also beware that zip file format does not include the encoding of the files 
>> that are in the
>> zip file.
> 
> 
> For the encoding of the contents, well since we are
> packaging python code files, it's handling will be the same
> as handling outside the zip file. It's handling is the
> same as how zipapp handles things.

I replies seperaly about this problem.
> 
>> This means that for practical purposes only ASCII filenames are portable 
>> across
>> systems. Is this limitation a problem for this proposal?
> 
> 
> If we are talking about filenames, then i guess
> ascii filenames are the way to go as you'd 
> unnecessarily break things otherwise.

Barry___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/L6H6LGU2J32QA5I2Z6NCTGQGEZ2YQFCW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a PyObject_VaCallFunction to C API??

[Greg Ewing]

On 8/01/20 9:22 am, hrfu...@gmail.com wrote:

how can I know if a PyObject_Call(...) or PyObject_GetAttr(...)
returns a new ref or a borrowed ref? I read online ( Python 3 ) that
they are returning new references. But does everyone comply with it?


They always return new references. Yes, everyone complies with it.
(If they don't, their code crashes the interpreter and they get a
visit from the Spanish Inquisition.)

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7VTFSBGKSBB7PEIZMK3G4KIUECIKHMZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Integrating Discourse and email for python-ideas

[Juancarlo Añez]

>
> There are important and interesting discussions taking place both on
Discourse (https://discuss.python.org) and on this email list (Mailman?).

Discourse has email integration (
https://discourse.gnome.org/t/interacting-with-discourse-via-email/46).

I prefer the rich-text and thorough threading provided by Discourse.

Could we switch the email discussions to Discourse email? Has this been
considered earlier and rejected?

Cheers,

-- 
Juancarlo *Añez*
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/26OF3GV4TJV5QWPQ3OZRMO4AWAUOMV7U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Integrating Discourse and email for python-ideas

[Stephen J. Turnbull]

Juancarlo Añez writes:

 > Could we switch the email discussions to Discourse email? Has this been
 > considered earlier and rejected?

Yes, of course we can.  It has been brought up several times.  It
hasn't been rejected, but there's strong opposition.

Eg, based on my experience with Discourse and its mail capabilities,
I'd probably just stop participating (with no great loss to either
Python-Ideas or to me ;-).  Others are more invested, and have
expressed their opposition in "oh gawd please NO!" terms.

For the practical implications of Discourse vs. Mailman for people
like me who are heavily invested in email-based workflows, you'll have
to find those earlier threads.

Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XU64HZX2CMQVG5ZHY2F2ZASSUTYMDHBA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Stephen J. Turnbull]

Barry writes:

 > Have a look at this write up about the horror that is zip file name
 > handling.

As I implied, I don't need to "read write-ups", *I live the horror.*
Not daily, but always when I really don't want to spend the minutes.

 > This has been a pain point at work.

I know your pain.  But this PEP is not about your work environment
(does it include Japanese bureaucrats? ;-/), it's about a file format
that we control.  (More specifically, Mr. Janhangeer does.)  The
question (in any normal case) is simply how does the system default
file name encoding interact with the PEP, and my guess is "if we take
a bit of care, it doesn't."

Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CUQVKC7AGOFGUDLVOBQLPM5GS3TOGAVR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Integrating Discourse and email for python-ideas

[David Mertz]

"oh gawd please NO!"

On Tue, Jan 7, 2020, 9:40 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Juancarlo Añez writes:
>
>  > Could we switch the email discussions to Discourse email? Has this been
>  > considered earlier and rejected?
>
> Yes, of course we can.  It has been brought up several times.  It
> hasn't been rejected, but there's strong opposition.
>
> Eg, based on my experience with Discourse and its mail capabilities,
> I'd probably just stop participating (with no great loss to either
> Python-Ideas or to me ;-).  Others are more invested, and have
> expressed their opposition in "oh gawd please NO!" terms.
>
> For the practical implications of Discourse vs. Mailman for people
> like me who are heavily invested in email-based workflows, you'll have
> to find those earlier threads.
>
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/XU64HZX2CMQVG5ZHY2F2ZASSUTYMDHBA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PYRHIMXXT4VDRKHBODRYFWCZM5HPTFZT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Christopher Barker]

On Mon, Jan 6, 2020 at 10:50 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:


> - More metadata
>

good idea, and simple.


> - Integrity check with hashing
> - Protecting the meta data
>

This could be a big challenge -- and I'm not expert, so have no idea what
the issues are.


> - Bundling 3rd party packages
>

Well, as you state below, that could make it big. but it also could make it
useful -- folks want to use environments of various sorts to keep
dependencies separate, so bundling them all up in an app would be nice.

But a thought on that -- you may be able to accomplish something similar
with conda, "conda constructor", and "conda run". -- or a new tool built
from those. The idea is that the first time you ran your "app", it would
install its dependencies, and then use them in an isolated environment. But
if the multiple apps had the same dependencies, they would share them, so
you wouldn't get major bloat on the host machine.


> Are you aiming for a bundle that can run on multiple platforms? If so,
>> then it’ll have to have a way to bundle multiple compiled extensions and
>> select the right ones at runtime.
>>
>
> According to the discussion on the Python, Be Bold thread, it became
> clear that it will be a pain to generate and will have an unnecessary
> size but sure this a most stable idea
>
> Suggesting instead to include wheels. The wheels are installed. The
> interpreter looks for packages in that app-specific folder
>

but a wheel is just as big as the installed package (at least a zipped
version) -- it's essentially the package compressed into a tarball.

If this Is essentially just zipapp with the ability to bundle dependencies,
>> then you could probably just do some sys.path hackery.
>>
>
> Could you please explain more. Thanks?
>

sure -- in your zip file, you have a "dependencies" directory. the
dependencies get installed there. Then that dir gets added to sys.path at
startup. I'm not so sure o=how to do that inside a zipfile, but it could be
done *somehow*

In any case, thus seems like something you could implement, and then see if
>> people find it useful.
>>
>
> That's a nice idea to have a working demo. I'm not a security
> expert but i'll try!
>

well, you'll need a consult on the security issues -- which you would want
well reviewed anyway ;-)


> Anyone interested in this thread can view this tool
>  built by LinkedIn which
> attempts dependencies bundling.
>

There you go -- you've got half the job done already :-)

But: "Unlike “conventional” zipapps, shiv packs a site-packages style
directory of your tool’s dependencies into the resulting binary, and then
at bootstrap time extracts it into a ~/.shiv cache directory."

which is how they get around the "how to add a dir in a zip file to
sys.path" -- but I'll bet someone could hack that to no be neccesary

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WD2W5T5TLBLYRTPTRB5PRSEPI7GH5SBD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club  | github

Mauritius


On Wed, Jan 8, 2020 at 2:20 AM Barry  wrote:

>
> You are offing up a competitor against python wheels
>

This proposal proposes to inlcude python wheels in the archive


> Py2app, py2exe etc packagers.
>

Native executables are off the plate. This one deals with archive files.
But i
get the idea, thanks! Maybe you wanted to allude to projects like Shiv
 by
LinkedIn


> Explain the benefits and weaknesses compared to the existing alternatives.
>

There are some projects similar to Shiv, will write a comparison.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UZOTD3G37SP2IR4DJV2EA72YFDKC6EIS/
Code of Conduct: http://python.org/psf/codeofconduct/