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

[Marcus Smith]

>
>> The first thing that immediately stood out to me, is that it's
>> recommending
>> that downstream redistributors like Debian, Fedora, etc utilize Wheels
>> instead
>> of the sdist to build their packages from. However, that is not really
>> going to
>> fly with most (all?) of the downstream redistributors. Debian for
>> instance has
>> policy that requires the use of building all of it's packages from
>> Source, not
>> from anything else and Wheels are not a source package. While it can
>> theoretically work for pure python packages, it quickly devolves into a
>> mess
>> when you factor in packages that have any C code what so ever.
>>
>
> So wouldn't they then download the sdist, build a wheel as an
> intermediate, and then generate the .deb file?
>

the new goal I think was to have standardized metadata immediately
available in an sdist, and get away from the model, that you had to run a
build step, before you had a metadata artifact.
so here,  you'd have to build a wheel (potentially one with binary
extensions) just to know what the metadata is? that doesn't sound right.



> I mean as long as people upload an sdist for those that want to build from
> source and a wheel for convenience -- which is probably what most people
> providing wheels do anyway -- then I don't see the problem.
>
>
>>
>> Overall, this feels more like a sidegrade than an upgrade. One major theme
>> throughout of the PEP is that we're going to push to rely heavily on
>> wheels as
>> the primary format of installation. While that works well for things like
>> Debian, I don't think it's going to work as wheel for us. If we were only
>> distributing pure python packages, then yes absolutely, however given
>> that we
>> are not, we have to worry about ABI issues. Given that there is so many
>> different environments that a particular package might be installed into,
>> all
>> with different ABIs we have to assume that installing from source is still
>> going to be a primary path for end users to install and that we are never
>> going
>> to have a world where we can assume a Wheel in a repository.
>>
>> One of the problems with the current system, is that we have no mechanism
>> by
>> which to determine dependencies of a source distribution without
>> downloading
>> the file and executing some potentially untrusted code. This makes
>> dependency
>> resolution harder and much much slower than if we could read that
>> information
>> statically from a source distribution. This PEP doesn't offer anything in
>> the
>> way of solving this problem.
>>
>
> Isn't that what the requirements and requirements-file fields in the
> _pypackage file provide? Only if you use that requirements-dynamic would it
> require execcuting arbitrary code to gather dependency information, or am I
> missing something?
>

those are just requirements to run the build hook, not run time
dependencies.



> Is there another proposal I'm unaware for the sdist -> wheel step that is
> build tool-agnostic?
>

PEP426 talks about it some
https://www.python.org/dev/peps/pep-0426/#metabuild-system
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151002/be968971/attachment.html>