I like binary distribution even under Linux. I access some Linux machines using same Linux distribution and some of them doesn't have "python-dev" package or even "build-essensials". (because they are netbooting so have restricted rootfs size)
So I want build binary package by myself and distribute it to virtualenv on such machines. In this case, absolute path of virtualenv is not fixed. So "bdist_dumb --relative" or egg is good for me. On Sun, Oct 30, 2011 at 11:09 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > I'd like to reopen the discussions on how the new packaging module > will handle/support binary distributions in Python 3.3. The previous > thread (see > http://mail.python.org/pipermail/python-dev/2011-October/113956.html) > included a lot of good information and discussion, but ultimately > didn't reach any firm conclusions. > > First question - is this a Windows only problem, or do Unix/MacOS > users want binary support? My feeling is that it's not an issue for > them, at least not enough that anyone has done anything about it in > the past, so I'll focus on Windows here. > > Second question - is there a problem at all? For the majority of > Windows users, I suspect not. The existing bdist_wininst and bdist_msi > formats have worked fine for a long time, offer Windows integration > and a GUI installer, and in the case of MSI offer options for > integrating with corporate distribution policies that some users > consider significant, if not essential. (Binary eggs are a third, and > somewhat odd, case - a number of projects have started distributing > binary eggs, but I don't know what benefits they have over > bdist_wininst in particular, as easy_install will read bdist_wininst > installers. Perhaps a setuptools/distribute user could comment. For > now I'll assume that binary eggs will slowly go away as packaging gets > more widely adopted). > > So that leaves a minority who (1) prefer integration with packaging, > (2) need to work with virtual environments or custom local builds, (3) > need binary extensions in some or all of their environments and (4) > don't want to have to build all the binaries they need from scratch. > > Given the scale of the issue, it seems likely that putting significant > effort into addressing it is unwise. In particular, it seems unlikely > that developers are going to move en masse to a new distribution > format just to cater for this minority. On the other hand, for people > who care, the fact that packaging (currently) offers no direct support > for consuming binary distributions is a fairly obvious hole. And > having to build from source just to install into a virtual environment > could be a showstopper. > > The bdist_wininst format is relatively amenable to manipulation - it's > little more than a zip file, after all. So writing 3rd party code to > install the contents via packaging shouldn't be hard (I've done some > proof of concept work, and it isn't :-)) Vinay's proposal to use the > resource mechanism and some custom hooks would work, but I'd like to > see a small amount of extra direct support added to packaging to make > things cleaner. Also, if packaging supported plugins to recognise new > distribution formats, this would make it possible to integrate the > extra code seamlessly. > > The MSI format is a little more tricky, mainly because it is a more > complex format and (as far as I can tell from a brief check) files are > stored in the opaque CAB format, so the only way of getting data out > is to do a temporary install somewhere. But I see no reason why that > isn't achievable. > > So, my proposal is as follows: > > 1. I will write a 3rd party module to take bsist_wininst and bdist_msi > modules and install them using packaging > 2. Where packaging changes are useful to make installing binaries > easier, I'll request them (by supplying patches) > 3. I'll look at creating a format-handling plugin mechanism for > packaging. If it's viable, I'll post patches > 4. If it seems useful, my module could be integrated into the core > packaging module > > I don't intend to do anything about a GUI, or modify the existing > formats at all. These don't interest me, particularly, so I'll leave > them to someone who has a clear picture of what they want in those > areas, and the time to develop it. > > For 3.3 at least, I'd expect developers to continue distributing > bdist_wininst or bdist_msi format files. We'll see what happens with > binary eggs. > > Unix/MacOS users who care will need to propose something themselves. > > Does anyone have any comments? > > 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/songofacandy%40gmail.com > -- INADA Naoki <songofaca...@gmail.com> _______________________________________________ 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
