Sharing a python runtime dll
JKP
I wanted to request a new feature, which should not be hard to
implement at all. I have several programs which I package using
PyInstaller and I'd like to share a python runtime dll between them.
I know from looking at your launch.c code that you allow the user to
put a dll in the same directory as the script (or exe file as it
becomes). My request is to allow people to use a dll found in their
PATH.
Our system installer for the software I develop puts a python26.dll in
our own dlls directory. I'd like a way to let my PyInstaller apps to
reference that dll just like any other applications would reference a
required dll in our system.
If I can do this I can save quite a substantial amount of space
overall. I understand it's not something everyone would like but
having the flexibility would be nice. I'm happy to submit a patch
that would search the PATH for the python runtime if required.
Thanks in advance.
Jamie
Giovanni Bajo
To do this, it *should* be sufficient to exclude python26.dll from the
libraries being included in the PKG file. You can hand-edit the .spec
file: go throught the toc that's being passed to the PKG() call, and
remove the python26.dll.
OTOH, what you really want is to share as much as possible between your
executables. I'm going to add support for this quite soon (probably
within November, since it's a customer request): the idea is that a
single .pkg file will be built, containing all the dyanamic libraries
and Python modules required for all the binaries. Then, you would simply
get lightweight executables with only the boot scripts inside.
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
Don Dwiggins
> OTOH, what you really want is to share as much as possible between your
> executables. I'm going to add support for this quite soon (probably
> within November, since it's a customer request): the idea is that a
> single .pkg file will be built, containing all the dyanamic libraries
> and Python modules required for all the binaries. Then, you would simply
> get lightweight executables with only the boot scripts inside.
I'm looking forward to this; I've got a set of related utilities that
I've built as single-file executables, mostly out of laziness. I'd
really like to redo this as you describe. Question: would this require
a particular directory structure, or would there be a configurable way
to tell an executable where to look for its library?
(Actually, going a bit further, it'd be even nicer to have multiple
libraries, so. e.g., a subset of the executables that share modules and
binaries could reference the subset's library and the full set's
library, maybe via a kind of path mechanism. No hurry for this from me,
though; just fantasizing.)
--
Don Dwiggins
Advanced Publishing Technology
Jamie Kirkpatrick
Good to know something is on the radar. For my part I'd like to be able to share common set of extensions and dlls between several applications. I already exclude all the dlls that are installed as part of our normal install process, but I'm left having to embed the python.dll and our custom python module (which contains lots of .pyd compiled code) into each application. Ideally I could put this and the python.dll in some kind of support bundle and save myself as much space as possible.
Look forward to seeing what gets baked.
Jamie
Jamie Kirkpatrick
07818 422311
Giovanni Bajo
> Good to know something is on the radar. For my part I'd like to be able to
> share common set of extensions and dlls between several applications. I
> already exclude all the dlls that are installed as part of our normal
> install process, but I'm left having to embed the python.dll and our custom
> python module (which contains lots of .pyd compiled code) into each
> application. Ideally I could put this and the python.dll in some kind of
> support bundle and save myself as much space as possible.
The idea is that one should be able to decide what to share and what not
to share through the spec files, as the spec file will dictate what to
put within an executable and what to put into a separate PKG file.
For instance:
=================================================================
# -*- mode: python -*-
a = Analysis([os.path.join(HOMEPATH,'support\\_mountzlib.py'),
os.path.join(HOMEPATH,'support\\useUnicode.py'), 'foo.py'])
b = Analysis([os.path.join(HOMEPATH,'support\\_mountzlib.py'),
os.path.join(HOMEPATH,'support\\useUnicode.py'), 'bar.py')
pyz = PYZ(a.pure+b.pure)
pkg = PKG(a.scripts + b.scripts +
a.binaries + b.binaries +
a.zipfiles + b.zipfiles,
name=os.path.join('dist', "shared.pkg"))
exe1 = EXE([],
a.scripts,
exclude_binaries=1,
name=os.path.join('dist', 'foo.exe'),
debug=True,
strip=False,
upx=False,
console=True )
exe2 = EXE([],
b.scripts,
exclude_binaries=1,
name=os.path.join('dist', 'bar.exe'),
debug=True,
strip=False,
upx=False,
console=True )
=================================================================
The main problem in implementing this is that the bootloader currently
assumes there's only one .PKG file (global variables everywhere). And
you still need a (slim) PKG appended to each executable (the bootstrap
scripts).