[Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils
qwcode at gmail.com
Fri Oct 2 21:02:44 CEST 2015
>> The first thing that immediately stood out to me, is that it's
>> that downstream redistributors like Debian, Fedora, etc utilize Wheels
>> 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
>> 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,
>> 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
>> 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
>> which to determine dependencies of a source distribution without
>> the file and executing some potentially untrusted code. This makes
>> resolution harder and much much slower than if we could read that
>> statically from a source distribution. This PEP doesn't offer anything in
>> 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
> Is there another proposal I'm unaware for the sdist -> wheel step that is
> build tool-agnostic?
PEP426 talks about it some
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG