Mailing List Archive

Guido van Rossum wrote:
> Alternatively (and probably easier) it (and site.py) could be stored
> as frozen modules. All it takes is some edits to Python/frozen.c.

An excellent design, very simple. A large list of critical
Python-language modules including a new importer, imputils.py and
a new main could be reliably linked to their interpreter. It
would open the door writing a larger part of Python in Python.

But editing Python/frozen.c will kill the current freeze feature
since a user currently replaces this pointer with their own.
We can have a second _PyImport_InternalFrozenModules[] array which is
searched FIRST, so that the existing frozen modules feature
is retained. Current logic only allows one frozen module array.
This is easy.

A little harder is turning it off, which may be important to
developers. They will probably want to use site.py etc. in
PYTHONPATH directories. I would hate to use another command line
option.
Maybe another method in the imp module, say imp.EnablePyInternalLib(x)
to turn on/off the internal frozen modules. A method to print
the names in the list wouldn't hurt either.

At one time I had code for multiple frozen modules which I may
be able to find.

Jim Ahlstrom

> > you can do this without recompiling! The version string is used
is
> > embedded in a resource, so you can patch it using some kind of
> > resource editor. Mark Hammond planned it this way!
>
> I don't understand this. Is there documentation?

Vague documentation at
http://www.python.org/windows/python/registry.html

Doesnt explicitely say much about this particular issue, and if I
remember I will update it.

VC will allow you to edit these resources without rebuilding - simply
open the DLL, but select "Resources" as the file type. I havent
investigated other resource editors as I have MSVC :-)

Greg pointed you to the win32api functions - they do work, as Greg
provided code that uses them (the code he pointed at was done by
him) - although I never actually worked out how to make them work
( I spent about an hour trying to get code to re-stamp the
Python15.dll with a new sys.winver, and gave up. Would be cool to get
going tho...

Mark.

> Summary: I'm very interested in seeing import and import
> hooks get rationalized, and I think Greg's stuff goes a long,
> long way towards that goal.

don't have time to say much more than:

-- ME TOO!

(we're also doing this in the pythonworks
packager, and Greg's module is essential
for that work. might as well turn it into
a standard Python feature).

</F>

> But it doesn't help, perhaps as a result of more of my prejudices.
> This registry entry is meant to be used by a by-the-rules shared
> Python installation, so I must not change it.

No - the point is that the "1.5" key is "reserved" by a standard
install. Changing the string value actually allows you to have your
own subtree, and you can assume you own that.

For commercial apps I help with, re stick a "AppName" in this string
(doesnt have to be a number) then simply use
"HKLM\Software\Python\AppName"

> And I hate changing any registry entries at all.

Well, you should learn to get over it! That is what it is designed
for. sure, we dont want the users to muck with the registry, but if
you dont like your install scripts working with the registry, I
definately feel you should get over this prejudice of yours.

> only minimal and required registry entries. IMHO the Windows
registry
> is a software catastrophe which ranks right up there with JCL
(anyone
> else here old enough to remember that?). Anyone who doesn't agree
> should
> go with me to our money center banking clients, and sit there
> while they
> grill you on every registry entry and why it is required.
> Money center
> banking clients do not like their registry messed with.

The registry is a huge bucket. Changing your own, custom kep under
either HKLM\Software\ or HKCU\Software is perfectly reasonable.

Many apps _require_ you to hit the registry - services, event log,
performance monitor, etc.

The fact the registry _also_ contains critical information is a
problem, and sure, we dont want to mess with that.

> My current "solution" is to use freeze to create a black-box
install,
> and worry about second Python installations and wasted storage when
it
> happens.

well, IMO this is also the correct thing to do. any install that has
>100 files is fragile. So I do both - freeze the app, _and_ a custom
"sys.winver".

> I was hoping that this thread whould result in a consensis of what
> to do, but it has not.

There is a consesus for people with the same problem. Different
problems have different optimal solutions.

Mark.

Perhaps you have heard about the East coast US hurricane. It
really hammered us here in New Jersey. I had trouble getting
home last night due to high water. When I went to our usual
Japanese lunch restaurant it had broken windows and was full of tree
branches. Wow...

Anyway,

Mark Hammond wrote:
>
> No - the point is that the "1.5" key is "reserved" by a standard
> install. Changing the string value actually allows you to have your
> own subtree, and you can assume you own that.

OK, now that I know the rules I will think about doing that.

> > And I hate changing any registry entries at all.
>
> Well, you should learn to get over it!

I will try.

Of course, even if the registry helps ship Python apps
on Windows, it is no help on Unix, and I care about that
almost as much.

> > My current "solution" is to use freeze to create a black-box
> install,
> > and worry about second Python installations and wasted storage when
> it
> > happens.
>
> well, IMO this is also the correct thing to do. any install that has
> >100 files is fragile. So I do both - freeze the app, _and_ a custom
> "sys.winver".

Yes, but this requires a compiler.

> > I was hoping that this thread whould result in a consensis of what
> > to do, but it has not.
>
> There is a consesus for people with the same problem. Different
> problems have different optimal solutions.

The problem is that there is no reliable way to ship bullet-proof
Python apps without recompiling and rebuilding Python. Each of us
has his own pet hack to solve our own problem. Now there is talk
of custom import hooks, and this is likely to result in each
package requiring its own import hook! Aren't packages supposed
to be software IC's?

I hate to be a nag, but I will keep pushing for a single solution.
Python is totally cross platform, and with all that machinery,
there must be portable way to do that.

I think this is good for Python. Please don't think I am
trying to solve my own selfish problems. I have a compiler,
I am happy using freeze, and I don't have any problems. Its
just that Python would "sell" better and be more popular
if a developer could read the documentation "How to ship
and install your Python app in five minutes and make
millions". This documentation currently reads "You can't".

Jim Ahlstrom

Greg Stein wrote:
>
> Skip Montanaro wrote:
> >
> > Gordon> In the soon-to-be-published beta version of my installer, I've
> > Gordon> got that down to exceptions.py.
> >
> > Why not just run exceptions.py through Python2C, visually and experimentally
> > verify that it works, then ship an exceptions.c as an optional module?

Optional module... Good idea.

But it is easier to use freeze within the optional module. So I
wrote a "boot" built in module, where bootmodule.c is
created by the Python program bootmake.py. All this lives in
./Modules. Boot incorporates exceptions.pyc etc. as frozen modules
without breaking the current freeze feature. I changed pythonrun.c
to load "boot" after sys but before any other imports, but only if
it exists as a built in module, otherwise no error. Boot has
methods to turn it on and off, and to print its contents.

Please take a look at ftp://ftp.interet.com/pub/bootmodule.html

I think this is a good solution for how to build in imputil.py.

Jim Ahlstrom