[Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

Oscar Benjamin oscar.j.benjamin at gmail.com
Thu Oct 8 12:18:22 CEST 2015


On 7 October 2015 at 22:41, Paul Moore <p.f.moore at gmail.com> wrote:
> On 7 October 2015 at 22:28, Nathaniel Smith <njs at pobox.com> wrote:
>> Maybe I have misunderstood: does it actually help pip at all to have
>> static access to name and version, but not to anything else? I've been
>> assuming not, but I don't think anyone's pointed to any examples yet
>> of the problems that pip is encountering due to the lack of static
>> metadata -- would this actually be enough to solve them?
>
> The principle I am working on is that *all* metadata in a source wheel
> should be statically available - that's not just for pip, but for all
> other consumers, including distro packagers. What's not set in stone
> is precisely what (subsets of) metadata are appropriate for source
> wheels as opposed to (binary) wheels.

A concrete example would be whether or not the numpy source wheel
depends on pyopenblas. Depending on how numpy is built the binary
wheel may or may not depend on pyopenblas. It doesn't make any sense
to say that the numpy source release depends on pyopenblas so what
should be the dependencies of the source wheel?

One possibility which I think is what Nathaniel is getting at is that
there is a source release and then that could be used to generate
different possible source wheels each of which would correspond to a
particular configuration of numpy. Each source wheel would correspond
to one binary wheel and have all static metadata but there still needs
to be a separate source release that is used to generate the different
source wheels.

The step that turns a source wheel into a binary wheel would be
analogous to the ./configure step in a typical makefile project.
./configure is used to specify the options corresponding to all the
different ways of compiling and installing the project. After running
./configure the command "make" is unparametrised and performs the
actual compilation: this step is analogous to converting a source
wheel to a binary wheel.

I think this satisfies all of the requirements for static metadata and
one-to-one correspondence of source wheels and binary wheels. If numpy
followed this then I imagine that there would be a single source wheel
on PyPI corresponding to the one configuration that would be used
consistently there. However numpy still needs to separately release
the code in a form that is also usable in all of the many other
contexts that it is already used. IOW they will need to continue to
issue source releases in more or less the same form as today. It makes
sense for PyPI to host the source release archives on the project page
even if pip will simply ignore them.

--
Oscar


More information about the Distutils-SIG mailing list