On 25/03/2009 6:51 AM, "Martin v. Löwis" wrote: >> Mike Driscoll did some work providing Windows installers for various >> Python packages and extension modules, and people were amused that he >> provided executable installers for pure Python libraries. But I saw that >> as a sensible decision, since it meant that Windows users (and even >> Windows Python application developers) used the same mechanism to >> install everything. > > The Windows story is indeed sad, as none of the Windows packaging > formats provides support for dependencies (MSI has some support, > but as far as I understand it, it's pretty useless). But yes, for > Windows, you want .exe or .msi installers, not something proprietary. Isn't this discussion slightly at cross-purposes? * py2exe doesn't create *installers*, just the target application. It (poorly) manages dependencies on the build machine. There doesn't seem to be a need for runtime dependency management in this tool. * The creation of an *installer* is something quite different. An installer for a py2exe based tool also doesn't need dependency management. An installer for a pure-python package that made no attempt to bundle dependencies might be nice, but I don't quite see how that falls outside the scope of distutils/setuptools/etc. In other words, I don't see why the installer can't bootstrap the 'normal' dependency management which would be used if the package was installed any other way or on other platforms. * distutils already has the ability to create Windows installer executables for pure-python apps/libs. I agree it would be nice if it was an MSI but that is an implementation detail rather than implementation requirement. How were Mike's packages fundamentally different than that? Cheers, Mark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4