By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,677 Members | 1,890 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,677 IT Pros & Developers. It's quick & easy.

Python Webstart ?

P: n/a
huy
Hi,

Just wondering if there were any plans (or existing projects) similar to
Java webstart for Python. I think this would be a boon for python. I
would love to start my new project using Python but the deployment (and
long term upgrading) factor is a major itch which pyfreeze and py2exe
just doesn't scratch properly.

Thanks

Huy
Jul 18 '05 #1
Share this Question
Share on Google+
24 Replies


P: n/a
Am Fri, 17 Sep 2004 21:43:04 +1000 schrieb huy:
Hi,

Just wondering if there were any plans (or existing projects) similar to
Java webstart for Python. I think this would be a boon for python. I
would love to start my new project using Python but the deployment (and
long term upgrading) factor is a major itch which pyfreeze and py2exe
just doesn't scratch properly.


Hi,

what does webstart do?

Thomas

Jul 18 '05 #2

P: n/a
Thomas Guettler wrote:
what does webstart do?


nothing useful, and that's why there is no such beast for python.

Istvan.

Jul 18 '05 #3

P: n/a
On Fri, 17 Sep 2004 21:43:04 +1000, huy <ny*****@swiftdsl.com.au> wrote:
Hi,

Just wondering if there were any plans (or existing projects) similar to
Java webstart for Python. I think this would be a boon for python. I
would love to start my new project using Python but the deployment (and
long term upgrading) factor is a major itch which pyfreeze and py2exe
just doesn't scratch properly.


I sincerely don't understand why a Python Webstart would be more
useful than pyfreeze and py2exe. If you're talking about some way for
people to test your application without the need to install it, I can
get it, but still I don't think that it's worth it. Remember -- the
JVM is a near standard part of modern browsers, so it's relatively
safe to assume that a lot of people (those using modern GUI browsers)
will be able to test your program. But the Python VM is not designed
to work like that; in the end, the user still would need to download
some client library (a PyVM-plugin for browsers of sorts), which
pretty much defeats the point of the Python Webstart.

If you *really* want to program in Python and have it working with
Webstart, why not do it using Jython? Once compiled, a Jython program
is undistinguishable from a Java app -- both are meant to run under
the JVM. I don't know if anyone did it before, but running Jython
programs as Webstart applications should be possible, if not
automatic.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com
Jul 18 '05 #4

P: n/a
huy
Carlos Ribeiro wrote:
On Fri, 17 Sep 2004 21:43:04 +1000, huy <ny*****@swiftdsl.com.au> wrote:
Hi,

Just wondering if there were any plans (or existing projects) similar to
Java webstart for Python. I think this would be a boon for python. I
would love to start my new project using Python but the deployment (and
long term upgrading) factor is a major itch which pyfreeze and py2exe
just doesn't scratch properly.

I sincerely don't understand why a Python Webstart would be more
useful than pyfreeze and py2exe. If you're talking about some way for
people to test your application without the need to install it, I can
get it, but still I don't think that it's worth it. Remember -- the
JVM is a near standard part of modern browsers, so it's relatively
safe to assume that a lot of people (those using modern GUI browsers)
will be able to test your program. But the Python VM is not designed
to work like that; in the end, the user still would need to download
some client library (a PyVM-plugin for browsers of sorts), which
pretty much defeats the point of the Python Webstart.


Well not really. I don't mind doing one installation of a (Python/Java)
webstart. However, it's the automatic update of the actual application
software which I find most useful. The alternative using p2exe or
pyfreeze will require me to distribute the (potentially large) binaries
manually. For hundreds of terminals, this is not gonna be good,
especially in an iterative environment.
If you *really* want to program in Python and have it working with
Webstart, why not do it using Jython? Once compiled, a Jython program
is undistinguishable from a Java app -- both are meant to run under
the JVM. I don't know if anyone did it before, but running Jython
programs as Webstart applications should be possible, if not
automatic.


That's an option but I don't quite trust using jython for a full blown
application. I use it mainly for unittesting at the moment.

Thanks for the feedback,

Huy

Jul 18 '05 #5

P: n/a
Thomas Guettler wrote:
Am Fri, 17 Sep 2004 21:43:04 +1000 schrieb huy:
Hi,

Just wondering if there were any plans (or existing projects) similar to
Java webstart for Python. I think this would be a boon for python. I
would love to start my new project using Python but the deployment (and
long term upgrading) factor is a major itch which pyfreeze and py2exe
just doesn't scratch properly.


Hi,

what does webstart do?

Thomas

Actually it's very useful. In the Java world you can set a central location
that a webstart program checks for possible updates. It's very cool.
John
Jul 18 '05 #6

P: n/a
huy <ny*****@swiftdsl.com.au> writes:
Well not really. I don't mind doing one installation of a
(Python/Java) webstart. However, it's the automatic update of the
actual application software which I find most useful. The alternative
using p2exe or pyfreeze will require me to distribute the (potentially
large) binaries manually. For hundreds of terminals, this is not gonna
be good, especially in an iterative environment.
A network drive is not an option? I use that with several software. I
just update one copy and everybody has an updated copy of the software
the next time they run it.

What I miss is the option to update the already running clients when
they instantiate the class again, but then, this would probably include
performance penalties when there are no changes.
That's an option but I don't quite trust using jython for a full blown
application. I use it mainly for unittesting at the moment.


Have you found any problems with it? I think that some missing CPython
modules prevented me to give it more attention, but now I don't even
remember which ones... :-(

--
Godoy. <go***@ieee.org>
Jul 18 '05 #7

P: n/a
John Fabiani wrote:
Actually it's very useful. In the Java world you can set a central location
that a webstart program checks for possible updates. It's very cool.


Only that it doesn't really work in practice. Read more here:

http://www.dynamicobjects.com/d2r/ar...004_07_09.html
Istvan
Jul 18 '05 #8

P: n/a
Jorge Godoy wrote:
huy <ny*****@swiftdsl.com.au> writes:
Well not really. I don't mind doing one installation of a
(Python/Java) webstart. However, it's the automatic update of the
actual application software which I find most useful. The alternative
using p2exe or pyfreeze will require me to distribute the (potentially
large) binaries manually. For hundreds of terminals, this is not gonna
be good, especially in an iterative environment.


A network drive is not an option? I use that with several software. I
just update one copy and everybody has an updated copy of the software
the next time they run it.


Of course the problem with using a network drive is the size of the file
that is download everytime the program is run.

John

Jul 18 '05 #9

P: n/a
Istvan Albert wrote:
John Fabiani wrote:
Actually it's very useful. In the Java world you can set a central
location
that a webstart program checks for possible updates. It's very cool.


Only that it doesn't really work in practice. Read more here:

http://www.dynamicobjects.com/d2r/ar...004_07_09.html
Istvan

I agree it's not perfect - but I still think it's cool. I have only one
site that is using webstart. It took about a week to get everyone up to
speed and now it has worked like clock work for about a year.
John
Jul 18 '05 #10

P: n/a
huy wrote:
Just wondering if there were any plans (or existing projects) similar to
Java webstart for Python. I think this would be a boon for python. I
would love to start my new project using Python but the deployment (and
long term upgrading) factor is a major itch which pyfreeze and py2exe
just doesn't scratch properly.


One quick solution would be to install a cvs client together with
python. This would update just those files that have changed. Your
clients could even rollback to an earlier release should there be any
problems.

It doesn't have to be cvs. Some of the newer source code control systems
have the ability to update through HTTP, should there be some
restrictions because of a firewall.

A command line client would be quite enough as you would be calling it
from your program anyway. There is no need for your clients to learn
anything about it.

Daniel
Jul 18 '05 #11

P: n/a
huy
Jorge Godoy wrote:
huy <ny*****@swiftdsl.com.au> writes:

Well not really. I don't mind doing one installation of a
(Python/Java) webstart. However, it's the automatic update of the
actual application software which I find most useful. The alternative
using p2exe or pyfreeze will require me to distribute the (potentially
large) binaries manually. For hundreds of terminals, this is not gonna
be good, especially in an iterative environment.

A network drive is not an option? I use that with several software. I
just update one copy and everybody has an updated copy of the software
the next time they run it.

What I miss is the option to update the already running clients when
they instantiate the class again, but then, this would probably include
performance penalties when there are no changes.


It's not really a an option because the users are spread out across
multiple sites and are only accessible via http or email. Before someone
suggests a web app, this is not really an option either due to the type
of application.
That's an option but I don't quite trust using jython for a full blown
application. I use it mainly for unittesting at the moment.

Have you found any problems with it? I think that some missing CPython
modules prevented me to give it more attention, but now I don't even
remember which ones... :-(


I haven't found any problems with it. It works great with httpunit which
is how I'm using it at the moment. However, the community doesn't seem
as active so I'd rather stick to the CPython for my main apps. With Java
5 coming + better external tools eg. spring framework, swixml, I find
things like Jython are losing more of their edge.

Huy
Jul 18 '05 #12

P: n/a
huy
Istvan Albert wrote:
John Fabiani wrote:
Actually it's very useful. In the Java world you can set a central
location
that a webstart program checks for possible updates. It's very cool.

Only that it doesn't really work in practice. Read more here:

http://www.dynamicobjects.com/d2r/ar...004_07_09.html
Istvan


Thanks for the link Istvan. The article is very informative, but I'm
afraid I've used JWS extensively without such troubles. It's all about
training and managing user expectation. We had a very smooth rollout and
seamless upgrades now are paying many times over for the initial
investment in particular management of the initial installation.

Read the comments, there are some great tips on making it work. As I
said in my other posts. It isn't the initial automated installation
which is most important to me, but the longer term automatic upgrading
(which happens much more frequent over the years).

Huy
Jul 18 '05 #13

P: n/a
huy
John Fabiani wrote:
Istvan Albert wrote:

John Fabiani wrote:

Actually it's very useful. In the Java world you can set a central
location
that a webstart program checks for possible updates. It's very cool.


Only that it doesn't really work in practice. Read more here:

http://www.dynamicobjects.com/d2r/ar...004_07_09.html
Istvan


I agree it's not perfect - but I still think it's cool. I have only one
site that is using webstart. It took about a week to get everyone up to
speed and now it has worked like clock work for about a year.
John


Good stuff John. That's my experience as well. I think you don't see how
useful it is until you experience a project which knows how to use it well.

Huy
Jul 18 '05 #14

P: n/a
huy
Daniel Dittmar wrote:
huy wrote:
Just wondering if there were any plans (or existing projects) similar
to Java webstart for Python. I think this would be a boon for python.
I would love to start my new project using Python but the deployment
(and long term upgrading) factor is a major itch which pyfreeze and
py2exe just doesn't scratch properly.

One quick solution would be to install a cvs client together with
python. This would update just those files that have changed. Your
clients could even rollback to an earlier release should there be any
problems.

It doesn't have to be cvs. Some of the newer source code control systems
have the ability to update through HTTP, should there be some
restrictions because of a firewall.

A command line client would be quite enough as you would be calling it
from your program anyway. There is no need for your clients to learn
anything about it.

Daniel


Great idea Daniel. An SVN client would work well. I'll think about it
for a while but I think this would be a real option.

Huy
Jul 18 '05 #15

P: n/a
huy <ny*****@swiftdsl.com.au> wrote:
...
Great idea Daniel. An SVN client would work well. I'll think about it
for a while but I think this would be a real option.


SVN sounds attractive because, among other things, it's _designed_ to be
scripted with Python (and no doubt in other ways, but I've noticed the
Python part only). However, it sounds as if all you need is some
variant of "os.system('svn up')" at program start (_before_ importing
any module that is part of the app), so that 'cvs up' or any other
revision control system would be just as fine.

And most likely so would be a roll-your-own approach, which might go
something like...:

def check_for_updates(
local_ver_filepath, #where we remember version
remote_ver_url, #where the server does
local_zip_filepath, #where we keep the modules' zipfile
remote_zip_url, #where the server does
report_fun=None, #how to give feedback of downloads
):

# let's see if there have been any updates since we last ran
current_local_version = open(local_ver_filepath).read()
current_remote_version = urrlib.urlopen(remote_ver_url).read()

if current_local_version >= current_remote_version:
# nope, no update needed, let caller know
return False, current_local_version, current_remote_version

# updates! get the new set of modules into the right place
urllib.urlretrieve(remote_zip_url, local_zip_filepath, report_fun)

# make sure the modules' zipfile is on the sys.path
import sys
if local_zip_filepath not in sys.path:
sys.path.insert(0, local_zip_filepath)

# record out latest update, for the future
open(local_ver_filepath,'w').write(current_remote_ version)

# let caller know we did perform an update
return True, current_local_version, current_remote_version

There -- in barebones term, isn't that roughly what you need? Sure, you
can conceive enhancements of it, a lot of them -- enhanced error
handling (this one doesn't DO much...:-), a log of what was updated when
(that might take the place of the tiny local_ver_filepath file), keeping
version numbers in the same zipfile as the modules rather than in a
small separate file (you still want a separate URL on the server so you
can check that no update is needed as fast as possible, of course), etc,
etc. But, roughly speaking, it does appear to me that this
twelve-statements-or-less function just ight meet your need even better
than svn or cvs would... depending on your exact needs, of course!-)

This one relies on Python's ability to import from a zipfile (of course,
you _could_ easily unzip the file after downloading it if you wanted,
but still it hinges on the concept of one update == one download). If
your typical update is a module or two out of dozens making up your app,
this would be suboptimal -- you'd waste a lot of bandwidth repeating the
download of modules that are already just fine. svn or cvs would be
better here. Alternatively, if you're willing to assume more cleverness
server-side, you could get by with a single roundtrip -- s/thing like:

filepath, msg = urlretrieve(server_url % current_local_version)

if the current local version is already OK, the server would return an
empty file and a msg with some appropriate header you can test;
otherwise the server would zip, or better tar and gzip (or bzip2, even
better) the needed set of modules, based on the current local version
and the current remote/centralized on, and send that as the response,
with a msg with some headers that can be tested for that. Of course,
the _server_ could perfectly well use svn or cvs to keep track of what
modules must go into the archive. And while this does require a modicum
of intelligence on the server, it's nothing a perfectly plain CGI would
have any trouble doing.

The client would test the appropriate header of msg, then, if needed,
unzip or otherwise uncompress the filepath and finally remove it.

One advantage of each of these approaches is that you minimize what you
need to install on the client -- no need for any cvs or svn and thus
also no need for any of the dependencies of those systems. Any good old
plain vanilla Python installation on the client would suffice...
Alex
Jul 18 '05 #16

P: n/a
huy
Alex Martelli wrote:
huy <ny*****@swiftdsl.com.au> wrote:
...
Great idea Daniel. An SVN client would work well. I'll think about it
for a while but I think this would be a real option.

SVN sounds attractive because, among other things, it's _designed_ to be
scripted with Python (and no doubt in other ways, but I've noticed the
Python part only). However, it sounds as if all you need is some
variant of "os.system('svn up')" at program start (_before_ importing
any module that is part of the app), so that 'cvs up' or any other
revision control system would be just as fine.

And most likely so would be a roll-your-own approach, which might go
something like...:


[snip]
One advantage of each of these approaches is that you minimize what you
need to install on the client -- no need for any cvs or svn and thus
also no need for any of the dependencies of those systems. Any good old
plain vanilla Python installation on the client would suffice...


Hi Alex,

Thanks for the in depth response. They are all very nice ideas which I
will take on board. I may just roll my own as you have suggested. As
nothing standard exists it may be my best bet.

I'll probably end up with py2exe for an initial installation and then
similar code to that you have provided to run before my main app. I may
use a JNLP style file to specify modules/zips to avoid needing to have
any cgi on the server. It would be good to just have a PWS module which
will download my whole app as well as update it so first time it's run I
could download the main app.

Thanks again,

Huy
Jul 18 '05 #17

P: n/a
"huy" <ny*****@swiftdsl.com.au> wrote:
Well not really. I don't mind doing one installation of a (Python/Java) webstart. However, it's
the automatic update of the actual application software which I find most useful.


As long as you don't insist on upgrading Python itself all the time, that's
pretty easy. Here's how I usually do it:

1) Wrap the Python parts of your application in one or more ZIP archives.

2) Add a thin wrapper that can check for new versions of the ZIP archives
(and optionally install them) before starting the rest of the application:

if check_for_updates():
install_updates()
fix_path()
import my_application

3) Create a "platform" release that contains a python build, the extensions
you need, and a "baseline" version of your application. Use your favourite
tool for this purpose (eg. py2exe).

4) Let your users install the platform release.

5) When you prepare new versions, build new ZIP import packages
and put them where the wrapper can find them.

The wrapper can also install new versions of required extensions, offer
access to earlier versions of the application, etc.

I use a variation of this technique for the effbot.exe platform:

http://effbot.org/zone/effnews-exe.htm

Here, the core installer simply installs Python (2.1, in this case) plus some
extensions, and a default application. Updates and additional applications
are shipped as "effbot" files, which are basically zipped-up PYC archives.
Works like a charm.

</F>

Jul 18 '05 #18

P: n/a
Well not really. I don't mind doing one installation of a
(Python/Java) webstart. However, it's the automatic update of the
actual application software which I find most useful. The alternative
using p2exe or pyfreeze will require me to distribute the (potentially
large) binaries manually. For hundreds of terminals, this is not gonna
be good, especially in an iterative environment.

I'm probably being really really *really* obtuse here (and heaven knows
it wouldn't be the first time) - but what's preventing you from
including that functionality in the program itself, by use of (say)
querying an xml file on (say) a web server?

I do this, in various permutations depending on the context, and it's
certainly flexible, convenient and all that jazz.

I'm not picking holes here, more wondering what I've missed, or even if
my approach could be helpful...

*dons flameproofs*
Jul 18 '05 #19

P: n/a
Carlos Ribeiro <ca********@gmail.com> wrote in message news:<ma**************************************@pyt hon.org>...
On Fri, 17 Sep 2004 21:43:04 +1000, huy <ny*****@swiftdsl.com.au> wrote:
Hi,

Just wondering if there were any plans (or existing projects) similar to
Java webstart for Python. I think this would be a boon for python. I
would love to start my new project using Python but the deployment (and
long term upgrading) factor is a major itch which pyfreeze and py2exe
just doesn't scratch properly.


I sincerely don't understand why a Python Webstart would be more
useful than pyfreeze and py2exe.


then you really don't understand what WebStart does.
Jul 18 '05 #20

P: n/a
>> I sincerely don't understand why a Python Webstart would be more
useful than pyfreeze and py2exe.


then you really don't understand what WebStart does.


I object to different packaging systems than my OS uses. When I use
Windows I expect programs to arrive as setup.exe, to add themselves
to the Add/Remove programs in the Control Panel etc. On Redhat boxes,
I expect them to arrive as rpms. On my Gentoo box, I expect them
to be part of portage.

The problem I have with webstart and systems of its ilk is that
they introduce yet another packaging mechanism disjoint from that
of the OS. Sure they try to make it convenient. But as a user
I really don't care that something is being packaged in a particular
way so it can be compatible with the packaging on other machines.
In fact as a user, I really don't care what programming language
is used for any programs, and I don't want hurdles.

Of course as a developer I do care about all that stuff, but trying
to expose it to users doesn't achieve anything.

Roger
Jul 18 '05 #21

P: n/a
huy
> But as a user
I really don't care that something is being packaged in a particular
way so it can be compatible with the packaging on other machines.
In fact as a user, I really don't care what programming language
is used for any programs, and I don't want hurdles.
Most of my users don't know as much as you do. What's an rpm ? what's a
programming language ? The users I know only know how to surf the web.
Of course as a developer I do care about all that stuff, but trying
to expose it to users doesn't achieve anything.


I'm not sure what you are trying to say here. Are you against webstart
or not ? Can't get easier then clicking on a link to install a program.

Huy
Jul 18 '05 #22

P: n/a
In article <1g*****************************@yahoo.com>,
Alex Martelli <al*****@yahoo.com> wrote:
huy <ny*****@swiftdsl.com.au> wrote:
...
Great idea Daniel. An SVN client would work well. I'll think about it
for a while but I think this would be a real option.


SVN sounds attractive because, among other things, it's _designed_ to be
scripted with Python (and no doubt in other ways, but I've noticed the
Python part only). However, it sounds as if all you need is some
variant of "os.system('svn up')" at program start (_before_ importing
any module that is part of the app), so that 'cvs up' or any other
revision control system would be just as fine.

And most likely so would be a roll-your-own approach, which might go
something like...:

Jul 18 '05 #23

P: n/a
Roger Binns wrote:
I object to different packaging systems than my OS uses. When I use
Windows I expect programs to arrive as setup.exe, to add themselves
to the Add/Remove programs in the Control Panel etc. ...


You probably use more programs than those on your desktop.
You can think of Google, Yahoo, eBay, etc. as web-based
applications for their specific tasks. These differ from
your OS in that they have no local installation. You go
to the right URL and start using it.

They also differ in that they have limited access to local
resources. I believe WebStart's goal is to expand on the
latter while acting like the former.

Andrew
da***@dalkescientific.com
Jul 18 '05 #24

P: n/a
huy wrote:
Most of my users don't know as much as you do. What's an rpm ? what's
a programming language ? The users I know only know how to surf the
web.
That is exactly what I am stating. On Windows, they are used to
installing stuff using setup.exe and on Linux using the vendor
packaging tool. Same for removing programs (Add/Remove Programs
and whatever the vendor tool is respectively).
I'm not sure what you are trying to say here. Are you against webstart
or not ? Can't get easier then clicking on a link to install a
program.


I am against the current implementations of webstart. They introduce
a parallel packaging system that isn't the same as the one already
on the user's OS.

Roger
Jul 18 '05 #25

This discussion thread is closed

Replies have been disabled for this discussion.