> I disagree with this. Your approach certainly works if you have an
> application which doesn't rely on lots of data files. The application
> which I am writing does requires those. It also needs to install itself
> into the registry/%path% because it is basically a "shared" application
> and other applications have to know about it somehow. I also need to
> create file associations so that the users can directly open files.
> Another thing worth mentioning is that installers put your program in the
> start menu folder, something which an exe alone does not do.
> As a user I don't mind installations if they're done properly. That is,
> you run the setup.exe, then you run the program out of the start menu
> folder and when you don't need the program anymore just go and click the
> "Uninstall" button in the start menu. Can't be much easier.
This can be done even with lots of data. If file association is required...
then it could be done upon first start, same with the start menu items.
Uninstall could be handled by a container monitor (the app modifies the
start menu and notifies the container that it did so in order for the
container to know what it needs to delete beside the app) For example one
app that already does this very nice is utorrent. You just download the .exe
add everything works.
>
> Updating an app only twice per year is not a good habit in my opinion.
> Either the application deserves to be updated more often (you find bugs
> faster, users will benefit from new features more easily, ...) or it can
> slowly die anyways.
Incremental updates can be implemented and I was talking about a container,
something like the Flash Player for example, something that allows for the
use of these hypothetical pyapps.
I'm not a very good programmer due to lack of strong structured thinking but
I can see connections and opportunities. I *know* without a shadow of a
doubt that this could be done if there is enough will and I also *know* that
there is tremendous benefit in something like this.
Of course it could be done - it's been done already, for every OS
platform except Windows. The deployment issues you're talking about
are really only problems there.
Pretty much every Linux environment, as well as the BSDs and even many
commercial Unixes have a standard packaging format with dependency
managment.
OS X has it's app bundles, which work basically like py2exe does. OS X
also ships with Python (and, in recent versions, wxPython) so you're
saved some extra dependency trouble there. Regardless, OS X users are
used to large, monolithic app bundles that are simply run in place.
Windows is the only major (and stands out even among the minor) OS
environments that doesn't have a standard way of managing packaging.
It's left up to individual developers, and that's lead to the entire
"installer" industry on that platform.
Because there's no standard, platform specific way of doing it, and
because there are so many individual developers, I don't think the
packaging of a "python runtime" for Windows is really going to spare
anyone very much effort. It'd be a lot of work to create, it'd require
someone to host the core python installer somewhere, and in the end I
don't think it would save users much work and I don't think it'd save
developers many questions.
···
On 2/20/07, Peter Damoc <pdamoc@gmail.com> wrote:
On 2/20/07, Nitro <nitro@dr-code.org> wrote:
Peter.
--
There is NO FATE, we are the creators.
