On 7 October 2015 at 22:53, Nathaniel Smith <n...@pobox.com> wrote: >> I think I'm as confused by what you're saying here as Donald is. Could >> you give a few examples of such projects? I'd like to go & take a look >> at them and try to understand what they are doing that is so >> incompatible with what Donald and I are thinking of as a"source >> wheel". > > An example would be flit itself: > https://github.com/takluyver/flit > https://pypi.python.org/pypi/flit > > It's not that you couldn't support a "source wheel" here, it's just > that forcing them to go checkout -> source wheel -> wheel would be > adding pointless hassle while accomplishing nothing useful. pip would > never actually touch the source wheel, and for the remaining use cases > for source distribution, a classic "source release" that's basically a > tarball of a VCS checkout + static version number would be more > familiar and useful.
I'm not sure I follow. If you have a binary wheel of flit, "pip install flit" won't need a source wheel, certainly (that's just as true for flit as for something complex like numpy). But distro packages would still want a source wheel to build their packages. If you mean that flit itself wouldn't use a source wheel, then while that may well be true, it's hardly relevant - whether flit chooses to use a source wheel is its own choice. But I'd hope flit *could* use a source wheel, as otherwise I couldn't use it to build wheels for other projects which want to use it and distribute source wheels. Should any such exist - this is pretty hypothetical at this point, and so not likely to be very productive. I am inclined to think that we're basically in agreement, we're just confused over terminology, and/or worrying about hypothetical cases. Would it help if I said that the *only* distinction between "source release" and source wheel that I care about is that in a source wheel the metadata must be static? We can discuss what metadata precisely, and we can thrash out other differences that might make more use of the fact that conceptually a "source release" is for humans to work with whereas a source wheel is for tools to consume, but those are details. I'm not clear if you think I have some more complicated picture than that, but really I don't [1]. Paul [1] I'd like a source wheel to have a defined format, but even that's not a killer. A zipfile with 2 directories "metadata" containing machine readable static metadata, and "source" with the complete contents of a source release, would do me. Of course when you build, if the metadata the build produces doesn't match the static data, that's a bug in the project packaging and we'd want to guard against it (it's the main reason the static data in the current sdist format is useless, that we can't rely on it :-() We can thrash this sort of stuff out, though. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
