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). > 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? Regards, Vinay Sajip _______________________________________________ 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