> >> 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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
