Donald Stufft <donald <at> stufft.io> writes: > I think we need to reconsider this. I cannot stress how badly an idea > I think it is for Wheels to concern itself with the ability to add the > Wheel to sys.path and import it.
I know that people have had bad experiences in the past with eggs, for the reasons Nick outlined in his response. However, you don't say *with specifics* why you think putting wheels on sys.path is a bad idea - I don't think it's convincing enough just to hand-wavingly reference problems with the egg format. When this topic came up before, I asked for specific failure modes which were causing concern, but I never got a response IIRC. One can't say that having the same packaging and importable formats is inherently bad, since Java shows otherwise. So if there are specific problems, they should be identified. > Further more it won't even work accurately for all Wheels (as Nick's > edit says) so we require that people wanting to do this figure out if > their Wheel can or can not be added to the sys.path (which isn't as > simple as looking at the tags because a platform specific Wheel may only > contain optional C modules). I don't yet see a technical impediment here. For example, distlib's wheel implementation uses a "mount" method to add a wheel to sys.path. This uses the tags to check for compatibility - there's no "figuring out" that the user has to do. If additional metadata about C extensions is available (which it is, if the wheel is built from source using distil), then those extensions are made available for import, too. I realise that's an extension to the current spec, but then no one is forcing any one to use it. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
