Distribution of latest Python and wxPython, using Java model

wxPython Users
1

Hello,
These days, in order for people to want to adopt
software it has to be made easy ...

How about making 3 different distributions of wxPython
available:

-1- A Java JRE-like wxPython distribution that is a
combination of the latest Python and wxPython
distributions but without any developer specific files
such as sample code, developer docs, etc. Just the
basic runtime environment for installation on a user's
machine.

-2- A developer wxPython SDK-type distribution that
contains the latest wxPython AND the latest Python
distributions.

-3- The current wxPython-only developer distribution.

(I'm sure this has been suggested before but I
couldn't find anything in the list archive)

Just a thought,
Thanks!

···

__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25�
http://photos.yahoo.com/ph/print_splash

2

a1opinion@yahoo.com wrote:

Hello,
These days, in order for people to want to adopt
software it has to be made easy ...

(I'm sure this has been suggested before but I
couldn't find anything in the list archive)

There has been noise made about creating a wxPython runtime of some sort, but I don't think any serious proposals about what it would look like have been put forth. I'd like to hear some....

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

3

a1opinion@yahoo.com wrote:

Hello,
These days, in order for people to want to adopt
software it has to be made easy ...

How about making 3 different distributions of wxPython
available:

-1- A Java JRE-like wxPython distribution that is a
combination of the latest Python and wxPython
distributions but without any developer specific files
such as sample code, developer docs, etc. Just the
basic runtime environment for installation on a user's
machine.

-2- A developer wxPython SDK-type distribution that
contains the latest wxPython AND the latest Python
distributions.

-3- The current wxPython-only developer distribution.

(I'm sure this has been suggested before but I
couldn't find anything in the list archive)

I've had thoughts similar to (1) in the past. See http://alldunn.com/wxPython/todo/notes107.html (This is from a *very* old dump of my todo list. Don't take anything you read there seriously <wink>) Now that Python supports loading packages from .zip files (.pyz in the todo not) then this would probably be a lot simpler to accomplish than in the past.

It would be great if somebody could work on a script that can generate something like (1) from a standard install of wxPython. I can provide guidance and further ideas I've had over the years since I wrote that todo, and then once it is ready I can encorporate that into my build and releases.

We would also need a tool that would help developers build apps that are deployable on machines that have a wxPRE installed. (This would have to be a bit different than just providing the end user a .py file in case the target machine also has a regular Python install, but it could be made to be very simple for the simple cases, and still very doable for the more complex cases.)

If the wxPRE is made versionable and allows multiple versions installed then the issues raised in the multiple installs thread would be solved too. Developers would just need to have the latest wxPython installed, but they could have multiple wxPREs installed and the apps needing the older verisons will just use the wxPRE.

(2) could simply be (1) plus the docs and demos, but I don't see much value of that over just providing (3) as always.

Anybody want to volunteer to drive this forward?

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

4

Robin Dunn wrote:

I've had thoughts similar to (1) in the past. See http://alldunn.com/wxPython/todo/notes107.html (This is from a *very* old dump of my todo list.

Some of my thoughts (commenting on Robin's notes):

* Can be associated to execute arbitrary single .py (??) files as
well single file archives (.pyz)

-Why not *.wxp files, or something like that? Using a different extension would help prevent clashes with other python applications. How I long for a #! line, like on *nix)

-In any case, let's build versioning in from the start!

* Can be launched from a browser to run downloaded .pyz files

-Very Cool.

* Includes Python DLLs, a PYZ archive of the standard Python
library, wxPython, and a few other popular packages

-Why a PYZ archive of the standard lib? why not just the regular version?

- What packages? this could easily explode! Perhaps rather than having it include the other popular packages, it could have an easy way to install other packages. If nothing else:

wxPython setup.py install

should work

The extra packages could be included with an app, and it's installer could check if it's already installed, but that could get a bit ugly, for lots of reasons, including the same versioning problem we've been talking about. We can solve it for wxPython, but not for everyone else!

This is really bugging me...the current situation is like everyone using dynamic libraries that don't have any version numbers..we all know what a nightmare that is.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

5

People on the twisted ML were talking about that too. Dunno if you're
subscribed to it, Chris, but I think you should take a look there. I can
forward you my copy of the gmane mirrored article if you want.

Be seeing you,

···

On Ter 20 Abr 2004 17:02, Chris Barker wrote:

This is really bugging me...the current situation is like everyone using
dynamic libraries that don't have any version numbers..we all know what
a nightmare that is.

--
Godoy. <godoy@ieee.org>

6

Maybe having better support to freeze and py2exe would be a nice way to
start. Those applications aren't cross platform, but they might help
getting some results easily and fast. A better approach could be decided
based on such experience.

···

On Ter 20 Abr 2004 16:09, Chris Barker wrote:

There has been noise made about creating a wxPython runtime of some
sort, but I don't think any serious proposals about what it would look
like have been put forth. I'd like to hear some....

--
Godoy. <godoy@ieee.org>

7

It would be great if somebody could work on a script that can generate something like (1) from a standard install of wxPython. I can provide guidance and further ideas I've had over the years since I wrote that todo, and then once it is ready I can encorporate that into my build and releases.

Is there an open line of comunication with the py2exe people? They can help a lot as they have been working with this for some time :smiley:

We would also need a tool that would help developers build apps that are deployable on machines that have a wxPRE installed. (This would have to be a bit different than just providing the end user a .py file in case the target machine also has a regular Python install, but it could be made to be very simple for the simple cases, and still very doable for the more complex cases.)

a JAR-like approach should do the trick, the manifest could contain info about the modules it needs (versions too) and the container could take care of the enviroment (switch between versions of modules, suggest download, suggest update)

If the wxPRE is made versionable and allows multiple versions installed then the issues raised in the multiple installs thread would be solved too. Developers would just need to have the latest wxPython installed, but they could have multiple wxPREs installed and the apps needing the older verisons will just use the wxPRE.

(2) could simply be (1) plus the docs and demos, but I don't see much value of that over just providing (3) as always.

I think the value of (2) is convenience, is nice to have one thing installed instead of 2.
It's worth mentioning that 2 might look a little bit like a "standard" python install with 2 "default" GUI toolkits :wink:

Anybody want to volunteer to drive this forward?

I volunteer for testing anything. :smiley: BANZAI! :smiley:

···

On Tue, 20 Apr 2004 12:13:06 -0700, Robin Dunn <robin@alldunn.com> wrote:

--
Peter Damoc
Hacker Wannabe
http://www.sigmacore.net/about.html

8

"Peter Damoc" <pdamoc@gmx.net> writes:

It would be great if somebody could work on a script that can
generate something like (1) from a standard install of wxPython. I
can provide guidance and further ideas I've had over the years
since I wrote that todo, and then once it is ready I can
encorporate that into my build and releases.

Is there an open line of comunication with the py2exe people? They can
help a lot as they have been working with this for some time :smiley:

I'm listening here ;-).
And I even have the same problem as Chris: I have to distribute a few
small apps using wxPython, currently I'm using 2.4.something, and I
don't want to port them to the newest and greatest wxPython for no
reason at all - they're stable.
OTOH, I'd like to make sure that py2exe is at least compatible with the
most current version of all the packages (well, some...) out there.

Thomas

···

On Tue, 20 Apr 2004 12:13:06 -0700, Robin Dunn <robin@alldunn.com> wrote:

9

Peter Damoc wrote:

We would also need a tool that would help developers build apps that are deployable on machines that have a wxPRE installed. (This would have to be a bit different than just providing the end user a .py file in case the target machine also has a regular Python install, but it could be made to be very simple for the simple cases, and still very doable for the more complex cases.)

a JAR-like approach should do the trick, the manifest could contain info about the modules it needs (versions too) and the container could take care of the enviroment (switch between versions of modules, suggest download, suggest update)

The modules dependency is an issue. I would recommend including all non-standard modules inside the app, since otherwise we're having to evolve a package management tool alongside the wxPRE - I nice thing, but a more complex (and different) task.

If the wxPRE is made versionable and allows multiple versions installed then the issues raised in the multiple installs thread would be solved too. Developers would just need to have the latest wxPython installed, but they could have multiple wxPREs installed and the apps needing the older verisons will just use the wxPRE.

(2) could simply be (1) plus the docs and demos, but I don't see much value of that over just providing (3) as always.

I think the value of (2) is convenience, is nice to have one thing installed instead of 2.
It's worth mentioning that 2 might look a little bit like a "standard" python install with 2 "default" GUI toolkits :wink:

Then why shouldn't 2) just *be* a standard python install with 2 default GUI toolkits?
The difficulty I have had (at least on Windows) is that the "standard" python installer is quite difficult to create ... you have to have a particular version of a non-open source installer program etc. If this situation could be improved it would make 2) a lot easier to create - simply add the GUI toolkits to the standard python installer...

David

···

On Tue, 20 Apr 2004 12:13:06 -0700, Robin Dunn <robin@alldunn.com> wrote:

10

Robin Dunn wrote:

Hello,
These days, in order for people to want to adopt
software it has to be made easy ...

How about making 3 different distributions of wxPython
available:

-1- A Java JRE-like wxPython distribution that is a
combination of the latest Python and wxPython
distributions but without any developer specific files
such as sample code, developer docs, etc. Just the
basic runtime environment for installation on a user's
machine.

-2- A developer wxPython SDK-type distribution that
contains the latest wxPython AND the latest Python
distributions.

-3- The current wxPython-only developer distribution.

(I'm sure this has been suggested before but I
couldn't find anything in the list archive)

I've had thoughts similar to (1) in the past. See http://alldunn.com/wxPython/todo/notes107.html (This is from a *very* old dump of my todo list. Don't take anything you read there seriously <wink>) Now that Python supports loading packages from .zip files (.pyz in the todo not) then this would probably be a lot simpler to accomplish than in the past.

It would be great if somebody could work on a script that can generate something like (1) from a standard install of wxPython. I can provide guidance and further ideas I've had over the years since I wrote that todo, and then once it is ready I can encorporate that into my build and releases.

We would also need a tool that would help developers build apps that are deployable on machines that have a wxPRE installed. (This would have to be a bit different than just providing the end user a .py file in case the target machine also has a regular Python install, but it could be made to be very simple for the simple cases, and still very doable for the more complex cases.)

If the wxPRE is made versionable and allows multiple versions installed then the issues raised in the multiple installs thread would be solved too. Developers would just need to have the latest wxPython installed, but they could have multiple wxPREs installed and the apps needing the older verisons will just use the wxPRE.

(2) could simply be (1) plus the docs and demos, but I don't see much value of that over just providing (3) as always.

Anybody want to volunteer to drive this forward?

OK we actually *need* something like this if we want to deploy wxPython apps for our customers, so I'm keen to have a go...
Some observations:
Some things to decide:
- how to store wxPRE instances
    wxPRE could be an executable itself with things zipped into it (py2exe style)
    or it could simply be a python executable with the appropriate libraries in directories
- how to associate wxPRE apps with wxPRE (#!/ under unix, special association under windows?)
    for this, it would be good to have a multi-version capability
    so that means that the app itself should be able to enumerate wxPRE instances and choose one.
    nice-to-have: locate and download an appropriate wxPRE if none is installed.
- how to handle extra modules
    many apps will have extra dependencies
    currently these are installed into site-packages
    maybe they should just be bundled with the app here?
- how to create wxPRE installers
    I propose this should be a simple distutils setup.py script, and any extra code needed included with wxPython

It would be good if a wxPRE application installer could contain a wxPRE installer, and install it if neccessary.

The focus should be on how we would gain advantages over a standard Python install with wxWindows installed into it.
For me the main aims would be
1) Having a single easy-to-use installer for wxPRE that combines Python and wxWindows
2) Minimising download size (not including unneccessary docs etc)
3) Allowing simply download & installation of wxPRE apps
4) Providing a reliable way to handle multiple wx versions

I don't see that putting things in zip files would neccessarily aid any of the above, although it would save disk space etc.
But in terms of launching the applications, it seems to make sense to have a wxPRE executable (ala py2exe).
The key thing would be to workout away to handle multiple wx versions ... probably a simple script that picks up the required version from the wxPRE app and finds the best wxPRE available and runs the app with it.

Ideas, comments?

David

···

a1opinion@yahoo.com wrote:

11

Chris Barker wrote:

Robin Dunn wrote:

I've had thoughts similar to (1) in the past. See http://alldunn.com/wxPython/todo/notes107.html (This is from a *very* old dump of my todo list.

Some of my thoughts (commenting on Robin's notes):

* Can be associated to execute arbitrary single .py (??) files as
well single file archives (.pyz)

-Why not *.wxp files, or something like that? Using a different extension would help prevent clashes with other python applications. How I long for a #! line, like on *nix)

Yep. That's what the (??) was all about.

-In any case, let's build versioning in from the start!

* Can be launched from a browser to run downloaded .pyz files

-Very Cool.

* Includes Python DLLs, a PYZ archive of the standard Python
library, wxPython, and a few other popular packages

-Why a PYZ archive of the standard lib? why not just the regular version?

Since Python can now import from a zip file it makes sense to bundle it that way in the runtime instead of exploading out a couple hundred files on the user's system that they theoretically never need to look at.

- What packages? this could easily explode! Perhaps rather than having it include the other popular packages, it could have an easy way to install other packages. If nothing else:

wxPython setup.py install

should work

Yep.

The extra packages could be included with an app, and it's installer could check if it's already installed,

Or they could just be installed with the app, not inserted into the wxPRE.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

12

David Fraser wrote:

OK we actually *need* something like this if we want to deploy wxPython apps for our customers, so I'm keen to have a go...
Some observations:
Some things to decide:
- how to store wxPRE instances
   wxPRE could be an executable itself with things zipped into it (py2exe style)
   or it could simply be a python executable with the appropriate libraries in directories

Or perhaps a small shell app that determines which version of wxPRE is needed and then loads it dynamically from the set of wxPRE's that are installed

  .../wxPRE/wxPRE.exe
  .../wxPRE/versions/2.5.1/wxPRE-2.5.1.exe
  .../wxPRE/versions/2.5.1/*.dll, *.pyd, etc.
  .../wxPRE/versions/2.6/wxPRE-2.6.exe

etc.

- how to associate wxPRE apps with wxPRE (#!/ under unix, special association under windows?)
   for this, it would be good to have a multi-version capability
   so that means that the app itself should be able to enumerate wxPRE instances and choose one.
   nice-to-have: locate and download an appropriate wxPRE if none is installed.

Yep.

- how to handle extra modules
   many apps will have extra dependencies
   currently these are installed into site-packages
   maybe they should just be bundled with the app here?

I think so.

- how to create wxPRE installers
   I propose this should be a simple distutils setup.py script, and any extra code needed included with wxPython

Yep, that works.

It would be good if a wxPRE application installer could contain a wxPRE installer, and install it if neccessary.

Yep. Or people could have two installers available, one with wxPRE and one with just their own app to dave download time.

The focus should be on how we would gain advantages over a standard Python install with wxWindows installed into it.
For me the main aims would be
1) Having a single easy-to-use installer for wxPRE that combines Python and wxWindows
2) Minimising download size (not including unneccessary docs etc)
3) Allowing simply download & installation of wxPRE apps
4) Providing a reliable way to handle multiple wx versions

I don't see that putting things in zip files would neccessarily aid any of the above, although it would save disk space etc.

I think that a runtime environment installed as a dir with a few EXE's, DLL's, PYD's and ZIP's is easier to accept that a whole directory tree with hundreds of fiels in it.

But in terms of launching the applications, it seems to make sense to have a wxPRE executable (ala py2exe).

Yep.

The key thing would be to workout away to handle multiple wx versions ... probably a simple script that picks up the required version from the wxPRE app and finds the best wxPRE available and runs the app with it.

yep.

Ideas, comments?

We should probably start documenting the issues, ideas, etc. on a set of wiki pages that can then be morphed into a design/spec over time. Do you want to start it?

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

13

Jorge Godoy wrote:

Maybe having better support to freeze and py2exe would be a nice way to
start.

A better Py2exe (or BundleBuilder, or...) would be nice, but not what I, at least, am looking for. I'm looking for a run time environment that could be shared among many wxPython apps. There is a place for each approach.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov