Windows发布建议？ [英] Windows distribution suggestions?

问题描述

对于某些东西或其他东西必须要忏悔，我需要发布一个Python应用程序，以便在Windows XP下使用。请温柔地对待我，因为

我是Un * x weenie，而且我在

下做了很多练习.Windows正在重新启动它。 />

我的应用程序包含三个不同的程序（比如alice.py，bob.py和

carol.py）需要可以独立启动，还有十几个或者所以

导入前三个的其他.py文件。我要点b $ b真正喜欢的是制作一个名为（例如）

" app.exe"的安装程序。启动app.exe应该完全安装Python，解压缩所有必要的模块，并在桌面上创建三个图标（alice，bob，carol）。


我知道有很多方法可以构建像这样的Windows发行版，但

我不确定目前首选的是什么。 Gordon McMillan的网站
www.mcmillan-inc.com 它的域名到期了（他真的应该在一些抢劫者抓住它之前更新

！）和我找到的镜子

表示它最后更新为Python 2.3。我在2.4下编写了我的应用程序

，虽然我不认为我严重依赖任何2.4

功能，但我宁愿不必降级只是为了制作这个exe

安装程序。还有py2exe - 那还不错吗？


此外，发布更新的首选方式是什么？也就是说，让我们想要更新我的.py文件并经常发布一个新版本

- 我是否应该每个新的.exe时间？会启动

新的一个干净地覆盖或卸载旧的？总计

凉爽将是一种运送update.py的方式。与应用程序一起，

将应用程序同步到Subversion存储库，但这可能是b / b
要求更多。


我在开发机器上安装了Visual C ++，如果有帮助的话。

As what must be penance for something or other, I''m needing to release
a Python app for use under Windows XP. Please be gentle with me since
I''m a Un*x weenie and the only thing I''ve had much practice with under
Windows is rebooting it.

My app contains three different programs (say alice.py, bob.py, and
carol.py) that need to be independently launchable, and a dozen or so
other .py files that get imported into those first three. What I''d
really really like is to make a single installer called (say)
"app.exe". Launching app.exe should completely install Python, unpack
all the necessary modules, and make three icons (alice, bob, carol) on
the desktop.

I know there''s various ways of building Windows distros like that, but
am not sure what''s currently preferred. Gordon McMillan''s site
www.mcmillan-inc.com has had its domain expire (he really should renew
it before some squatter grabs it!) and the mirror that I''ve found
indicates that it was last updated for Python 2.3. I wrote my app
under 2.4 and while I don''t think I depend heavily on any 2.4
features, I''d rather not have to downgrade just to make this exe
installer. There''s also py2exe--is that as good?

Also, what''s the preferred way of releasing updates? That is, let''s
say I want to update my .py files and release a new version fairly
frequently--should I just make a new .exe every time? Would launching
the new one cleanly overwrite or uninstall the old one? Total
coolness would be a way to ship an "update.py" along with the app,
that syncs the app up to a Subversion repository, but that may be
asking a bit much.

I do have Visual C++ installed on the development machine, if that helps.

推荐答案

Paul Rubin写道：

Paul Rubin wrote:

对于某些东西或其他东西必须要忏悔，我需要发布一个在Windows XP下使用的Python应用程序。请温柔地对待我，因为
我是Un * x weenie，而且我在
Windows下练习的唯一一件事就是重新启动它。

我的应用程序包含三个不同的程序（比如说alice.py，bob.py和
carol.py）需要可以独立启动，还有十几个其他的.py文件可以导入前三个。我真正喜欢的是制作一个名为（例如）
app.exe的安装程序。启动app.exe应该完全安装Python，解压所有必要的模块，并在桌面上制作三个图标（alice，bob，carol）。

我知道那里'有各种各样的方法来构建像这样的Windows发行版，但是
我不确定目前首选的是什么。 Gordon McMillan的网站
www.mcmillan-inc.com 它的域名到期了（他真的应该在一些抢劫者抓住之前更新它！）和我找到的镜子
表明它最后一次更新为Python 2.3。我在2.4下写了我的应用程序，虽然我不认为我严重依赖任何2.4
功能，但我不想降级只是为了制作这个exe
安装程序。还有py2exe - 那还不错吗？

另外，发布更新的首选方式是什么？也就是说，让我们说我想更新我的.py文件并经常发布一个新版本 - 我应该每次只刷一个新的.exe吗？是否会启动新的干净覆盖或卸载旧的？总的凉爽是一种运送update.py的方式。连同应用程序，
将应用程序同步到Subversion存储库，但这可能会有点问。

我在开发机器上安装了Visual C ++ ，如果这有帮助

As what must be penance for something or other, I''m needing to release
a Python app for use under Windows XP. Please be gentle with me since
I''m a Un*x weenie and the only thing I''ve had much practice with under
Windows is rebooting it.

My app contains three different programs (say alice.py, bob.py, and
carol.py) that need to be independently launchable, and a dozen or so
other .py files that get imported into those first three. What I''d
really really like is to make a single installer called (say)
"app.exe". Launching app.exe should completely install Python, unpack
all the necessary modules, and make three icons (alice, bob, carol) on
the desktop.

I know there''s various ways of building Windows distros like that, but
am not sure what''s currently preferred. Gordon McMillan''s site
www.mcmillan-inc.com has had its domain expire (he really should renew
it before some squatter grabs it!) and the mirror that I''ve found
indicates that it was last updated for Python 2.3. I wrote my app
under 2.4 and while I don''t think I depend heavily on any 2.4
features, I''d rather not have to downgrade just to make this exe
installer. There''s also py2exe--is that as good?

Also, what''s the preferred way of releasing updates? That is, let''s
say I want to update my .py files and release a new version fairly
frequently--should I just make a new .exe every time? Would launching
the new one cleanly overwrite or uninstall the old one? Total
coolness would be a way to ship an "update.py" along with the app,
that syncs the app up to a Subversion repository, but that may be
asking a bit much.

I do have Visual C++ installed on the development machine, if that helps

i我自己刚刚完成了这个过程。如果你确定你唯一的

将应用程序分发到windows xp系统，那么使用pysvn从svn更新是完全可能的

。 pysvn目前还不工作

win9x客户端。

py2exe - 使用它，它真好。它将你所有的库放在一个

library.zip文件中，然后用它来更新你的应用程序。

使用NSIS做一个漂亮的安装程序，你甚至可以如果需要，用它来发送

手动补丁。

如果你需要任何帮助让pysvn或其他部分工作给我一个

电子邮件我可以提供帮助。

i have just gone through this process myself. if your sure your only
distributing the app to windows xp system, then it''s perfectly possible
to update from an svn by using pysvn. pysvn doesn''t currently work on
win9x clients.
py2exe - use it, it''s damn good. it puts all your library''s in a
library.zip file which can then use to update your app.
make a nice neat installer using NSIS, you can even use it to send
manual patches if you need to.
if you need any help making the pysvn or other parts work give me an
email i can help.

Paul Rubin写道：

Paul Rubin wrote:

作为对某事或其他内容必须进行的忏悔，我需要发布一个在Windows XP下使用的Python应用程序。请温柔地对待我，因为
我是一个Un * x weenie，而且我在
Windows下进行了多次练习，重新启动它。


我能感受到你的不快乐，我分享它。嗨保罗！

这里有一些提示...

我的应用程序包含三个不同的程序（比如alice.py，bob.py和
carol.py ）需要可独立启动，以及十几个其他.py文件，这些文件将被导入前三个。我真正喜欢的是制作一个名为（例如）
app.exe的安装程序。启动app.exe应该完全安装Python，解压所有必要的模块，并在桌面上制作三个图标（alice，bob，carol）。


由于您的安装程序需要在安装Python之前运行，因此您需要

。转到 http://www.wisesolutions.com

你''会找到一个Windows安装程序，带有一个演示版（30天

许可证）。试试这个，这将是我最好的建议。
我知道有各种方法可以构建像这样的Windows发行版，但是
我不确定目前首选的是什么。 Gordon McMillan的网站
www.mcmillan-inc.com 它的域名到期了（他真的应该在一些抢劫者抓住之前更新它！）和我找到的镜子
表明它最后一次更新为Python 2.3。我在2.4下写了我的应用程序，虽然我不认为我严重依赖任何2.4
功能，但我不想降级只是为了制作这个exe
安装程序。


无论如何，你必须在Windows上测试你的应用程序。

我已经构建了许多在两个世界中运行的应用程序（ Linux / Windows）。

通常这种方法有效，但有时候你将不得不处理奇怪的事情。一个是，如果你使用ODBC。您有必要在％SYSTEM％目录中处理
处理访问限制，除非您需要

管理员帐户您的应用程序。


如果您在Windows计算机上测试您的应用程序，您可以轻松地在同一台计算机上安装Python 2.3

和Python 2.4而不会发生冲突。试试看，如果你的

应用程序可以使用。如果它适用于两者，为什么不使用2.3？


还有py2exe - 那是好的吗？
取决于您的申请，如果可以接受的话。

我没有相关经验。
此外，发布更新的首选方式是什么？也就是说，让我们说我想更新我的.py文件并经常发布一个新版本 - 我应该每次只刷一个新的.exe吗？


提供一个名为Setup.exe或Install.exe的安装程序，它可以完成所有内容（由用户按下的一系列对话框引导

只有通过成功安装的返回键），是最先进的
。通常，其中一个Wise或InstallShield安装程序使用

。或简单的WinZip-Packages。

启动新的干净覆盖或卸载旧的？


如果你用适当的工具以正确的方式完成它，是的。

总的凉爽是一种运送更新的方式的.py"以及应用程序，
将应用程序同步到Subversion存储库，但这可能会有点问题。


谁是您的客户（您的计划发布的收件人）？

通常，您不能依赖他们可以在线访问您的存储库。

然后，他们可能对安全问题和/或稳定性感兴趣

的程序。我不喜欢一个据说需要经常更新的程序 - 我猜它内部质量不高......


如果您的应用程序有GUI，则菜单条目可能会获取您的更新文件

并将它们放置在必须驻留的位置。你的update.py可能会提供

菜单条目。非常简单。

如果您有命令行应用程序，为什么不提供额外的update.py

然后，如果您提供更新，只需使用已安装的

update.py。唯一的事情：你如何跟踪路径/桌面/文件

信息以及如何处理用户权限等？

你知道这是怎么回事在WindowsXP下完成？它与旧版Windows平台的价格大不相同！因此，将它留给

专业安装工具可能会更容易。

我在开发机器上安装了Visual C ++，如果有帮助的话。

As what must be penance for something or other, I''m needing to release
a Python app for use under Windows XP. Please be gentle with me since
I''m a Un*x weenie and the only thing I''ve had much practice with under
Windows is rebooting it.
I can feel your unhappiness, and I share it. Hi Paul!
Here are some hints...
My app contains three different programs (say alice.py, bob.py, and
carol.py) that need to be independently launchable, and a dozen or so
other .py files that get imported into those first three. What I''d
really really like is to make a single installer called (say)
"app.exe". Launching app.exe should completely install Python, unpack
all the necessary modules, and make three icons (alice, bob, carol) on
the desktop.
Since your installer needs to run before Python is installed, you need
something else. Go to http://www.wisesolutions.com
You''ll find a Windows installer program, with a demo-version (30days
license). Try this, it would be my best recommendation.
I know there''s various ways of building Windows distros like that, but
am not sure what''s currently preferred. Gordon McMillan''s site
www.mcmillan-inc.com has had its domain expire (he really should renew
it before some squatter grabs it!) and the mirror that I''ve found
indicates that it was last updated for Python 2.3. I wrote my app
under 2.4 and while I don''t think I depend heavily on any 2.4
features, I''d rather not have to downgrade just to make this exe
installer.
You''ll have to test your application on Windows, in any case.
I''ve built lots of applications which run in both worlds (Linux/Windows).
Usually this works, but occasionally you''ll have to deal with strange
things. One is, if you use ODBC. There''s good chance that you''ll have to
deal with access restrictions in the %SYSTEM% directory, unless you require
an administrator''s account for your application.

If you test your app on a Windows machine, you can easily install Python 2.3
and Python 2.4 on the same machine without conflicts. Just try out, if your
app works with either. If it works with both, why not use 2.3?

There''s also py2exe--is that as good? Depends on your application, if that is acceptable.
I have no experiences with that.
Also, what''s the preferred way of releasing updates? That is, let''s
say I want to update my .py files and release a new version fairly
frequently--should I just make a new .exe every time?
Providing an installation program called Setup.exe or Install.exe which does
everything (guided by a sequence of dialog boxes where the user presses
only the return key to get through the successful installation), is
state-of-the-art. Usually, one of the Wise or InstallShield installers, are
used. Or simple WinZip-Packages.
Would launching the new one cleanly overwrite or uninstall the old one?
If you''ve done it in the proper way with the proper tool, yes.
Total coolness would be a way to ship an "update.py" along with the app,
that syncs the app up to a Subversion repository, but that may be
asking a bit much.
Who are your customer''s (the recipients of your program releases)?
Usually, you cannot rely that they have online access to your repository.
Then, they are potentionally interested in security issues and/or stability
of the program. I''d not like a program which is said to require frequent
updates - I''d guess that there''s not much quality inside...

If your application has a GUI, a menu entry might fetch your update files
and place them wherever they must reside. your update.py might feed that
menu entry. Quite easy.
If you have command line apps, why not provide an additional update.py
and then, if you provide updates, just install them using your installed
update.py. The only thing: How do you keep track of path/desktop/file
information and how do you deal with user rights etc.?
Are you aware of how this is done under WindowsXP? It''s quite different from
older Windows platforms! Therefore it might be easier, to leave this to
professional installation tools.

I do have Visual C++ installed on the development machine, if that helps.

是不是Visual C ++仍然带有受限制的InstallShield版本？

如果是这样，请检查是否可以使用它。它可能会给你的发布带来一种专业的闪亮......


你肯定会发现，管理注册表/桌面文件系统<如果你想将你的应用程序发布到WindowsXP，那么
将耗费大部分精力。

一旦Python运行你的应用程序，剩下的就是花生。


Bernhard

Isn''t Visual C++ still coming with a restricted version of InstallShield?
If so, check if you can use that. It might give your release a sort of
professional shine...

You''ll certainly find out, that managing the registry/desktop file system
will cost most energy, if you want to release your apps to WindowsXP.
Once Python is running your apps, the rest is peanuts.

Bernhard

Bernhard Holzmayer< Ho **************** @ deadspam.com>写道：

Bernhard Holzmayer <Ho****************@deadspam.com> writes:

我可以感受到你的不快乐，我分享了它。嗨保罗！
这里有一些提示...


谢谢！ ;-)

由于您的安装程序需要在安装Python之前运行，因此您需要其他内容。转到 http://www.wisesolutions.com
你会发现Windows安装程序，带有演示版（30天
许可证）。试试这个，这将是我最好的建议。


嗯，好吧，看起来付费版本大约是500美元。由于这个

是一个Windows的东西我原则上可以使用付费软件包装

应用程序，但这有点昂贵的一面。我会看到

客户所说的但我认为他们可能会反对。

无论如何，你必须在Windows上测试你的应用程序。我已经构建了许多在两个世界中运行的应用程序（Linux / Windows）。
通常这有效，但偶尔你将不得不处理奇怪的事情。一个是，如果你使用ODBC。除非您需要管理员的应用程序帐户，否则很有可能您必须处理％SYSTEM％目录中的访问限制。


该应用程序现在在Windows下运行正常。我没有使用ODBC。稍后我可能需要一些数据库连接，并且可能会使用MySQL。我不想要b $ b想要一个管理员帐户。现在该应用程序只有一个Tkinter

gui，读取和写入一些文件并与一些套接字进行对话。我可能

稍后需要添加一些C扩展但这些应该是非常便携的。

如果你在Windows机器上测试你的应用程序，你可以轻松安装
Python 2.3和Python 2.4在同一台机器上没有冲突。如果您的应用适用于其中任何一种，请尝试一下。如果它与两者兼容，为什么不使用2.3？


我想我能做到这一点。我相信我会稍微使用2.4功能

但我可以改装那些东西。

I can feel your unhappiness, and I share it. Hi Paul!
Here are some hints...
Thanks! ;-)
Since your installer needs to run before Python is installed, you need
something else. Go to http://www.wisesolutions.com
You''ll find a Windows installer program, with a demo-version (30days
license). Try this, it would be my best recommendation.
Hmm, ok, it looks like the paid version is around 500 USD. Since this
is a Windows thing I''m ok in principle with using a payware packaging
app, but that''s a bit on the expensive side. I''ll see what the
customer says but I think they might resist.
You''ll have to test your application on Windows, in any case.
I''ve built lots of applications which run in both worlds (Linux/Windows).
Usually this works, but occasionally you''ll have to deal with strange
things. One is, if you use ODBC. There''s good chance that you''ll have to
deal with access restrictions in the %SYSTEM% directory, unless you require
an administrator''s account for your application.
The app works ok under Windows now. I don''t use ODBC. I might need
some database connectivity later and will probably use MySQL. I don''t
want to need an admin account. Right now the app just has a Tkinter
gui, reads and writes a few files and talks to some sockets. I might
need to add some C extensions later but those should be pretty portable.
If you test your app on a Windows machine, you can easily install
Python 2.3 and Python 2.4 on the same machine without
conflicts. Just try out, if your app works with either. If it works
with both, why not use 2.3?
I guess I could do that. I believe I make some minor use of 2.4 features
but I can probably retrofit those things.

有'还有py2exe - 那还不错吗？

There''s also py2exe--is that as good?

取决于你的应用程序，如果可以接受的话。
我对此没有任何经验。

Depends on your application, if that is acceptable.
I have no experiences with that.

我也不是。我希望找出它的优点和缺点，比较

与替代品。

谁是你的客户（你的程序发布的收件人）？通常，您不能依赖他们可以在线访问您的存储库。
然后，他们可能对安全问题和/或程序的稳定性感兴趣。我不喜欢一个据说需要经常更新的程序 - 我猜它内部质量不高......


该计划正在积极开发中，并且每隔几分钟就会发布新功能

。我们的想法是每周发布一次新的开发版本，供客户内部使用。

如果您的应用程序有GUI，菜单条目可能会提取您的更新文件
并将它们放在必须居住的任何地方。您的update.py可能会提供该菜单条目。很容易。


嗯，这是我要编码的另一件事 - 也许这是可行的。我会

想一想。

如果你有命令行应用程序，为什么不提供额外的update.py
然后，如果你提供更新，只需使用已安装的
update.py安装它们。唯一的事情：你如何跟踪路径/桌面/文件
信息以及如何处理用户权限等？
你知道在WindowsXP下如何做到这一点？它与旧版Windows平台完全不同！因此，将其留给专业安装工具可能会更容易。


我对Windows真的一无所知。我只是将应用程序的文件放在

C：/ Program Files / appname中，因为这就是其他开发人员之所以说b $ b所说的话。 />

Me neither. I was hoping to find out its good and bad points as compared
with alternatives.
Who are your customer''s (the recipients of your program releases)?
Usually, you cannot rely that they have online access to your repository.
Then, they are potentionally interested in security issues and/or stability
of the program. I''d not like a program which is said to require frequent
updates - I''d guess that there''s not much quality inside...
The program is under active development and sprouting new features
every few minutes. The idea is to release a new development build once
a week or so, for internal use by the customer.
If your application has a GUI, a menu entry might fetch your update files
and place them wherever they must reside. your update.py might feed that
menu entry. Quite easy.
Hmm, that''s another thing I''d have to code--maybe it''s feasible. I''ll
think about it.
If you have command line apps, why not provide an additional update.py
and then, if you provide updates, just install them using your installed
update.py. The only thing: How do you keep track of path/desktop/file
information and how do you deal with user rights etc.?
Are you aware of how this is done under WindowsXP? It''s quite different from
older Windows platforms! Therefore it might be easier, to leave this to
professional installation tools.
No I''m really ignorant about Windows. I just put the app''s files in
C:/Program Files/appname because that''s what one of the other developers
said to do.

我确实在开发机器上安装了Visual C ++，如果有帮助的话。

I do have Visual C++ installed on the development machine, if that helps.

不可视C ++仍然带有受限制的InstallShield版本？
如果是这样，请检查是否可以使用它。它可能会给你的发布带来一种专业的光泽...

Isn''t Visual C++ still coming with a restricted version of InstallShield?
If so, check if you can use that. It might give your release a sort of
professional shine...

嗯，这真的很有趣。我怎么知道呢？

你肯定会发现，如果你想把你的应用程序发布到WindowsXP，管理注册表/桌面文件系统将花费最多的精力。一旦Python运行你的应用程序，剩下的就是花生。

Hmm, that''s really really interesting. How would I find out?
You''ll certainly find out, that managing the registry/desktop file system
will cost most energy, if you want to release your apps to WindowsXP.
Once Python is running your apps, the rest is peanuts.

哦，伙计，我希望避免那种程度的麻烦。我的应用程序没有使用它自己的任何注册表项，但我猜Python可执行文件确实是这样的，并且这些东西可能必须随每个
重新安装，有些东西肯定会出错并且腐败

注册表，如果这就像我曾经习惯的Windows那样$ b $听到的。叹。在Windows XP下有多糟糕？

我已经习惯了Windows 95在最轻微的

错误时完全崩溃，但我的印象是XP有点更坚固。


也许我只需要告诉他们从它的

发行版MSI安装Python 2.4然后我就可以组建一个distutils设置.py thingie

他们将分开运行。这可能是客户可以接受的，如果它节省了大量的开发工作并且在出现问题时可以防止用户麻烦。如果有一个光滑的

一键安装程序肯定会很好。

Oh man, I was hoping to avoid that level of hassle. My app doesn''t
use any registry keys of its own, but I guess the Python executable
does, and that stuff presumably has to be updated with every
reinstall, and something is sure to eventually go wrong and corrupt
the registry, if this is anything like the Windows that I''m used to
hearing about. Sigh. Just how bad is that under Windows XP?
I''m used to Windows 95 completely falling apart at the slightest
error but I have the impression that XP is a bit more solid.

Maybe I''ll have to just tell them to install Python 2.4 from its
distro MSI and then I can put together a distutils setup.py thingie
which they''d run separately. That might be acceptable to the customer
if it saves a lot of development effort and prevents user hassles when
things go wrong. It would sure be nice to have one of those slick
one-click installers though.

这篇关于Windows发布建议？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！