On 10 October 2011 17:12, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > Paul Moore <p.f.moore <at> gmail.com> writes: > >> I'd propose that the install arguments used in bdist_wininst be >> transferred to bdist_dumb (or a new command bdist_binary created based >> on the same), because the bdist_wininst zip format has the following >> advantages: >> >> 1. Proven format, so it should deal with any edge cases like header >> files reasonably. And the code already exists. >> 2. Easily recognisable directory names (PLATLIB, PURELIB, etc) making >> detection easy without needing extra metadata. >> 3. At a pinch, a bdist_wininst installer could be treated as a dumb >> distribution without change (assuming the stdlib zip handling >> correctly ignores prepended data like the exe header). >> >> Then pysetup could be enhanced to recognise and install the binary >> format in pretty much the same way as it does source formats (add >> another install_method to _run_install_from_dir that copies the files >> to the target locations along with appropriate checking and/or >> metadata handling). > > A simple change to packaging will allow an archive containing a > setup.cfg-based > directory to be installed in the same way as a source directory. AFAICT this > gives a more useful result than bdist_wininst (as you typically want to > install > in more places than PURELIB and PLATLIB, and the setup.cfg scheme allows for > writing files to locations such as Powershell script directories for a user).
I'm not sure what you mean by a "setup.cfg-based directory". Could you clarify, and maybe explain how you'd expect to create such an archive? We may be talking at cross-purposes here. >> There might be a small amount of extra work to do, to check binary >> version compatibility, but that shouldn't be hard. >> >> If this is useful, I could look at creating a patch. (Once I get my >> build environment fixed so I can get 3.3 up and running - it looks >> like Python 3.3 can't be built with Visual C++ Express these days, the >> IDE can't convert the solution files because Express Edition doesn't >> support 64-bit. I'll have to fish out the full version and install >> that...) > > There's one thing that you touched on in an earlier post, which hasn't been > further discussed: support for virtual environments. The executable installer > format covers two things: packaging of version specific/compiled code, and the > simplicity of point-and-click installation. This latter convenience is worth > having, but the current installer stub (wininst-x.y.exe) does not know > anything > about virtual environments. If we care about virtual environment support (and > I > think we should), wininst.exe could be enhanced to provide a "Browse..." > button > to allow a user to select a virtual environment to install into, in addition > to > the detection of installed Pythons from the registry. If this is coupled with > the ability to invoke a setup.cfg-based installation when the appended archive > is for a setup.cfg-based directory tree, won't this pretty much tick all the > boxes? Agreed - but I'm looking at a pysetup install approach to work for source and binary packages, essentially replacing the use of bdist_wininst and bdist_msi with sdist/bdist_simple archives. That's a change of heart for me, as I used to argue for wininst/msi over setuptools and similar - but pysetup includes all the listing and uninstalling features I wanted, so the "one unified approach" has won me over in preference to the platform integration. Ideally bdist_wininst and bdist_msi would also integrate with pysetup and with virtual environments, but I imagine that could be pretty hard to make work cleanly, as Windows doesn't really support multiple installations of a software package... (Plus, I've no real idea about how bdist_wininst works, so while you may be right, I wouldn't know how to do anything with your suggestion :-)) 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
