PyInstaller needs Funding by your Company

[Hartmut Goebel]

Hi,

as some of you might already know:

PyInstaller is in urgent need of funding. If you are working for a
company using PyInstaller, please make them pay their share. For details
see 

*If reasonable funding is not achieved until end of January 2020,
@htgoebel  will retire as an maintainer.*
This basically means: Unless somebody else steps in, there will be
nobody reviewing any pull-request, there will be not improvement and
sooner or later you will not be able to use PyInstaller any more.

P.S.: Many thanks for those who donated from their personal money. We
really appreciate this!


  What is "sustainable funding"?

Maintianing PyInstaller at a proper level requires about 4 to 5 days per
month. Which means about 4,000 to 5,000 € per month and about 50,000 to
60,000 € per year.

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
https://www.goe-con.de/blog/bin-offiziell-entdecker-einer-sicherheitslucke
Kolumne:
https://www.goe-con.de/hartmut-goebel/cissp-gefluester/2012-01-in-die-cloud-in-die-cloud-aber-wo-soll-die-sein


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

Re: PyInstaller needs Funding by your Company

[Christian Gollwitzer]

Am 07.01.20 um 15:09 schrieb Hartmut Goebel:

Maintianing PyInstaller at a proper level requires about 4 to 5 days per
month. Which means about 4,000 to 5,000 € per month and about 50,000 to
60,000 € per year.


these numbers sound odd to me. 4000€ - 5000€ per month or equivalently 
60,000€ per year is the level of academic full-time jobs in Germany, 
i.e. that would be 4-5 days per week, not per month.


Christian

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

Re: PyInstaller needs Funding by your Company

[Hartmut Goebel]

Am 07.01.20 um 17:19 schrieb Christian Gollwitzer:
> Am 07.01.20 um 15:09 schrieb Hartmut Goebel:
>> Maintianing PyInstaller at a proper level requires about 4 to 5 days per
>> month. Which means about 4,000 to 5,000 € per month and about 50,000 to
>> 60,000 € per year.
>
> these numbers sound odd to me. 4000€ - 5000€ per month or equivalently
> 60,000€ per year is the level of academic full-time jobs in Germany,
> i.e. that would be 4-5 days per week, not per month.
>
Based on the hourly rate calculator at gulp.de, the average rate for
software developers is 85 €. This is a very specialized job, and I'm
senior, thus my rate should be a bit higher. Also this has to compete
with the offerings I get as a InfoSec consultant, which are above.

Please also keep in mind: PyInstaller is used by eg. Google, Docker,
CarbonBlack, Siemens, and quite some other really big ones. There is no
reason for me to spend my spare-time to make them earn money.

(Also your figure seems to not take into account the "Lohnnebenkosten" -
health insurance, pension fond, etc.)

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
https://www.goe-con.de/blog/openstreetmaps-hat-google-maps-weit-ueberholt
Kolumne:
https://www.goe-con.de/hartmut-goebel/cissp-gefluester/2011-08-horrorszenario-bring-your-own-device


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

Removing reference to local installed package

[Abdur-Rahmaan Janhangeer]

Greetings everybody,

I installed a local package using

python -m pip install 

Now if you install the same package from pypi, it says requirements already
satisfied pointing to the location of the local package folder instead of
site -package

pip uninstall does not work as the package is not in site-package in the
first
place

importing the package does not work as the package is not in site-package

it won't install and won't delete

Q: How do i remove the reference of  a local package?

Thanks

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club  | github

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

Re: Removing reference to local installed package

[DL Neil via Python-list]

On 8/01/20 8:53 AM, Abdur-Rahmaan Janhangeer wrote:

Greetings everybody,


Salaam,



I installed a local package using
python -m pip install 

Now if you install the same package from pypi, it says requirements already
satisfied pointing to the location of the local package folder instead of
site -package

pip uninstall does not work as the package is not in site-package in the
first
place
importing the package does not work as the package is not in site-package
it won't install and won't delete
Q: How do i remove the reference of  a local package?


Possibly relevant: 
https://stackoverflow.com/questions/33412974/how-to-uninstall-a-package-installed-with-pip-install-user



NB this problem avoided by using virtual environments/machines which are 
tailored to the individual application; thereby evincing no differences 
between 'system-wide' and 'lesser' installations.



Related?OT:
Is there a tool which will identify?estimate how packages were 
installed? eg pip[2] cf pip3, pip --user, pip system-wide, Linux apt/rpm 
installer, ...


...and thus how to uninstall! Also, because something installed one-way 
may (as described above) 'prevent' its installation in an alternate mode.



(experienced an issue where the version of pytest installed with/by/for 
the VS-Codium(?) add-on package differed from the one which I thought 
I'd just updated using (Linux Fedora's) DNF - the newer version 
requiring more recent dependencies that the IDE claimed 'weren't there'. 
It took quite a bit of circling around to determine the problem, and yet 
more to be sure of fixing it without causing 'collateral damage'!)

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

Re: [Python-ideas] 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

Re: [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-id...@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-id...@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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Floating point overflow and underflow

[Shashank Tiwari]

In Python3 an operation as follows:
>>> 10135.1941 * (10**8)
gives the result: 101351941.0001

Similarly, using the pow function also gives the same overflow/underflow
error.
>>> 10135.1941 * pow(10,8)
101351941.0001

Like multiplication, division of large or very small floating point numbers
gives similar overflow/underflow errors.

Usage of Decimal doesn't seem to fix it either.
>>> from decimal import *
>>> Decimal(10135.1941 * pow(10,8))
Decimal('101351941.0001220703125')
>>> Decimal(10135.1941)*pow(10,8)
Decimal('101351941.61700120568')
>>> Decimal(10135.1941) * Decimal(pow(10,8))
Decimal('101351941.61700120568')
>>> Decimal(10135.1941 * (10**8))
Decimal('101351941.0001220703125')

How could one do high precision multiplication and division of floating
points numbers (decimals) in Python3 without any overflow/underflow errors?

Thanks, Shanky
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Floating point overflow and underflow

[Rob Gaddi]

On 1/7/20 3:47 PM, Shashank Tiwari wrote:

In Python3 an operation as follows:

10135.1941 * (10**8)

gives the result: 101351941.0001

Similarly, using the pow function also gives the same overflow/underflow
error.

10135.1941 * pow(10,8)

101351941.0001

Like multiplication, division of large or very small floating point numbers
gives similar overflow/underflow errors.

Usage of Decimal doesn't seem to fix it either.

from decimal import *
Decimal(10135.1941 * pow(10,8))

Decimal('101351941.0001220703125')

Decimal(10135.1941)*pow(10,8)

Decimal('101351941.61700120568')

Decimal(10135.1941) * Decimal(pow(10,8))

Decimal('101351941.61700120568')

Decimal(10135.1941 * (10**8))

Decimal('101351941.0001220703125')

How could one do high precision multiplication and division of floating
points numbers (decimals) in Python3 without any overflow/underflow errors?

Thanks, Shanky



You've already polluted your Decimal with floating-point roundoff error before 
you even multiply it in any of your examples.


>>> Decimal(10135.1941)
Decimal('10135.19416170012056827545166015625')

Initialize your Decimal from a string instead.

>>> Decimal('10135.1941')
Decimal('10135.1941')
>>> Decimal('10135.1941') * Decimal('1e8')
Decimal('1.01351941E+12')
>>> float(_)
101351941.0
--
https://mail.python.org/mailman/listinfo/python-list

Re: Floating point overflow and underflow

[Shashank Tiwari]

Thanks Rob.

How would one initialize a Decimal with something like pow(2,256)?

On Tue, Jan 7, 2020 at 5:25 PM Rob Gaddi 
wrote:

> On 1/7/20 3:47 PM, Shashank Tiwari wrote:
> > In Python3 an operation as follows:
>  10135.1941 * (10**8)
> > gives the result: 101351941.0001
> >
> > Similarly, using the pow function also gives the same overflow/underflow
> > error.
>  10135.1941 * pow(10,8)
> > 101351941.0001
> >
> > Like multiplication, division of large or very small floating point
> numbers
> > gives similar overflow/underflow errors.
> >
> > Usage of Decimal doesn't seem to fix it either.
>  from decimal import *
>  Decimal(10135.1941 * pow(10,8))
> > Decimal('101351941.0001220703125')
>  Decimal(10135.1941)*pow(10,8)
> > Decimal('101351941.61700120568')
>  Decimal(10135.1941) * Decimal(pow(10,8))
> > Decimal('101351941.61700120568')
>  Decimal(10135.1941 * (10**8))
> > Decimal('101351941.0001220703125')
> >
> > How could one do high precision multiplication and division of floating
> > points numbers (decimals) in Python3 without any overflow/underflow
> errors?
> >
> > Thanks, Shanky
> >
>
> You've already polluted your Decimal with floating-point roundoff error
> before
> you even multiply it in any of your examples.
>
>  >>> Decimal(10135.1941)
> Decimal('10135.19416170012056827545166015625')
>
> Initialize your Decimal from a string instead.
>
>  >>> Decimal('10135.1941')
> Decimal('10135.1941')
>  >>> Decimal('10135.1941') * Decimal('1e8')
> Decimal('1.01351941E+12')
>  >>> float(_)
> 101351941.0
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Floating point overflow and underflow

[Chris Angelico]

On Wed, Jan 8, 2020 at 1:37 PM Shashank Tiwari  wrote:
>
> Thanks Rob.
>
> How would one initialize a Decimal with something like pow(2,256)?
>

Easy, just initialize it with an integer:

>>> Decimal(2**256)
Decimal('115792089237316195423570985008687907853269984665640564039457584007913129639936')

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

Re: Floating point overflow and underflow

[Shashank Tiwari]

Thanks Chris. What if it's pow(2.2,0.45)?

On Tue, Jan 7, 2020, 6:40 PM Chris Angelico  wrote:

> On Wed, Jan 8, 2020 at 1:37 PM Shashank Tiwari 
> wrote:
> >
> > Thanks Rob.
> >
> > How would one initialize a Decimal with something like pow(2,256)?
> >
>
> Easy, just initialize it with an integer:
>
> >>> Decimal(2**256)
>
> Decimal('115792089237316195423570985008687907853269984665640564039457584007913129639936')
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Floating point overflow and underflow

[Chris Angelico]

On Wed, Jan 8, 2020 at 2:18 PM Shashank Tiwari  wrote:
>
> Thanks Chris. What if it's pow(2.2,0.45)?
>

Initialize your Decimals from strings, as you were already advised,
and do the calculation in Decimals.

Or just use floats, since it's likely to be at least as accurate.

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

Re: Floating point overflow and underflow

[Michael Torrie]

On 1/7/20 8:18 PM, Shashank Tiwari wrote:
> Thanks Chris. What if it's pow(2.2,0.45)?

Why not do some more experimentation:

>>> import decimal
>>> a = decimal.Decimal('2.2')
>>> b = decimal.Decimal('0.45')
>>> a ** b
Decimal('1.425903734234490793207619170')

Is this what you mean? I'm sure there are other ways as well.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Floating point overflow and underflow

[Shashank Tiwari]

Yes, I tried this and it worked. I was wondering if I could use the output
of pow (or math.pow).

On Tue, Jan 7, 2020, 7:41 PM Michael Torrie  wrote:

> On 1/7/20 8:18 PM, Shashank Tiwari wrote:
> > Thanks Chris. What if it's pow(2.2,0.45)?
>
> Why not do some more experimentation:
>
> >>> import decimal
> >>> a = decimal.Decimal('2.2')
> >>> b = decimal.Decimal('0.45')
> >>> a ** b
> Decimal('1.425903734234490793207619170')
>
> Is this what you mean? I'm sure there are other ways as well.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Floating point overflow and underflow

[Shashank Tiwari]

Thanks everyone. Much appreciated.

On Tue, Jan 7, 2020, 7:46 PM Shashank Tiwari 
wrote:

> Yes, I tried this and it worked. I was wondering if I could use the output
> of pow (or math.pow).
>
> On Tue, Jan 7, 2020, 7:41 PM Michael Torrie  wrote:
>
>> On 1/7/20 8:18 PM, Shashank Tiwari wrote:
>> > Thanks Chris. What if it's pow(2.2,0.45)?
>>
>> Why not do some more experimentation:
>>
>> >>> import decimal
>> >>> a = decimal.Decimal('2.2')
>> >>> b = decimal.Decimal('0.45')
>> >>> a ** b
>> Decimal('1.425903734234490793207619170')
>>
>> Is this what you mean? I'm sure there are other ways as well.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Floating point overflow and underflow

[Michael Torrie]

On 1/7/20 8:46 PM, Shashank Tiwari wrote:
> Yes, I tried this and it worked. I was wondering if I could use the output
> of pow (or math.pow).

Sure:

pow(Decimal('2.2'), Decimal('0.45'))

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

Re: Floating point overflow and underflow

[Shashank Tiwari]

Oh, thanks. Didn't think of that.

On Tue, Jan 7, 2020, 7:53 PM Michael Torrie  wrote:

> On 1/7/20 8:46 PM, Shashank Tiwari wrote:
> > Yes, I tried this and it worked. I was wondering if I could use the
> output
> > of pow (or math.pow).
>
> Sure:
>
> pow(Decimal('2.2'), Decimal('0.45'))
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] 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.
-- 
https://mail.python.org/mailman/listinfo/python-list