On 14 October 2011 15:07, "Martin v. Löwis" <mar...@v.loewis.de> wrote: >> I can't really comment on this. I agree in principle with what you're >> saying, but I know little about the MSI format so I can't say much >> more. It feels to me like you're suggesting that the MSI file >> encapsulate the file layout logic that already has to exist in >> pysetup, though, which sounds like duplication of effort. Can MSI call >> out to pysetup to actually install the files and save this >> duplication? > > I'm not sure what exactly it is that pysetup does, so I can't say > whether there is any duplication. It's possibly to have post-install > actions in MSI, so if the files get put into (some) place at first, > it would be possible to copy/link them to whatever layout is needed.
OK, that might be a useful approach. > What I'd like to avoid is that people need to create too many different > packages on Windows, for different use cases. It would be better if > the author/packager could create one Windows distribution, and have > that work in all use cases. Absolutely. That is crucial if we're to avoid the sort of fragmentation we've seen in the past (with bdist_wininst, bdist_msi and binary eggs). I don't know if we'll ever get down to one format, but that would be the ideal. > As for MSI: it's primary advantages over bdist_wininst is the > higher flexibility of integration into systems maintenance > infrastructures. UI-less installation, installation through > Active Directory, nested installation (as part of some bundle > of installers) are all supported by MSI out of the box. IMO, > the primary reason to keep bdist_wininst (besides popularity) > is that you need to run the packaging on Windows to create an > MSI file, whereas bdist_wininst can be created cross-platform > (as long as there are no binary extension modules). In addition, > bdist_wininst is better wrt. to repeated installations. I'd > prefer a setup though where the same package can work in > multiple installations without requiring physical copies. One other aspect is that MSI format is essentially opaque (correct me if I'm wrong here). With bdist_msi, if I want to get the compiled binaries out for some reason (maybe to install them in a virtual environment or some type of other custom build) I just unzip the file - the exe header gets ignored. With bdist_msi, I have no idea if there's any way of doing that. Also, there are fewer people with expertise in MSI format. I suspect that even a Unix developer could have a go at modifying the C code in bdist_msi, it's not too MS-specific. I don't know if that's possible for bdist_msi. Speaking personally, the msilib documentation is pretty unreadable, as I don't know anything about the MSI format. Whenever I've tried reading the MS documentation in the past, I've found it pretty impenetrable (a link to a simple tutorial, and some examples of use, in the msilib documentation might help). Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com