On 25 August 2013 14:07, Donald Stufft <don...@stufft.io> wrote: > As far as I can tell there's nothing preventing Installing a Wheel *into* > and .egg > directory which will give you exactly the same situation as you have today > without needing to do *anything* except make a tool that will install a > Wheel > into an .egg directory. This solves your immediate desire without hanging > more things onto Wheel. >
I think that relating this to wheels is a mistake. As Donald says, wheels are just a distribution format. Looking at this from a different perspective, I don't see any immediate issue with being able to install distributions outside of site-packages. That's what pip's --target option does. It seems like the multi-versioning support that is being discussed is nothing much more than a means of managing such "not on site-packages" directory in a way that allows them to be added to sys.path at runtime. On that basis, I don't have an issue with the idea. It's supported in pip (via --target) already, and the runtime aspects can be handled in pkg_resources or wherever without affecting me. If, on the other hand, there is a proposal in here to change pip, then (a) I'd like to see what the explicit proposal is before commenting, (b) it should apply equally to all means by which you can install using pip (wheel and sdist - AFAIK --target has no meaning for --develop installs, and the same should be true here), and (c) it should not need any changes to the wheel format (again, I see no indication that it does, but I'd like to see that explicitly stated). The key point here is that I *don't* want wheel associated with all of the extra baggage that goes along with the egg concept. Even putting wheels on sys.path gives me a nervous feeling that we're reinventing eggs. I feel strongly that wheel is inventing bdist_simple rather than egg, and should continue to do so. As regards Nick's proposal: 1. "An option (or options) to pip, telling it to just drop a wheel file (or the unpacked contents of the wheel as a directory) into site-packages instead of installing the distribution directly as the default version." Well, if it's in site-packages, it *is* importable/installed. That's how site-packages works. So I don't understand what "instead of installing" means. But if --target does what you want then go for it. If you want something different then I think it's likely a bad idea, but I'd need details of how it would work to be sure. 2. "Support for the ".whl" filename format and internal layout in pkg_resources". No, very definitely -1. The wheel format is a *distribution* format and pkg_resources is a *runtime* mechanism. Misxing the two is the key mistake (in my mind) that setuptools made, and we do not want to do so again. If you need a multiversion runtime layout for pkg_resources, then let's define it in a PEP, and write installers to put packages into that format if we need to. But let's not just reuse wheel as that format - that was not its intent. If a distribution format better than wheel comes along in the future, we should be able to replace it without needing to break everyone's runtime code because pkg_resources doesn't know wbout it. Paul
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
