[Python-Dev] Status of packaging in 3.3 (original) (raw)

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Fri Jun 22 12:28:30 CEST 2012

On 06/22/2012 12:20 PM, David Cournapeau wrote:

On Fri, Jun 22, 2012 at 10:38 AM, Donald Stufft<donald.stufft at gmail.com> wrote:

On Friday, June 22, 2012 at 5:22 AM, Dag Sverre Seljebotn wrote:

What Bento does is have one metadata file for the source-package, and another metadata file (manifest) for the built-package. The latter is normally generated by the build process (but follows a standard nevertheless). Then that manifest is used for installation (through several available methods). From what I understand, this dist.(yml|json|ini) would be replacing the mainfest not the bento.info then. When bento builds a package compatible with the proposed format it would instead of generating it's own manifest it would generate the dist.(yml|json|ini). If by manifest you mean the build manifest, then that's not desirable: the manifest contains the explicit filenames, and those are platform/environment specific. You don't want this to be user-facing. The way it should work is: - package description (dist.yaml, setup.cfg, bento.info, whatever) - use this as input to the build process - build process produces a build manifest that is platform specific. It should be extremely simple, no conditional or anything, and should ideally be fed to both python and non-python programs. - build manifest is then the sole input to the process building installers (besides the actual build tree, of course). Conceptually, after the build, you can do : manifest = BuildManifest.fromfile("buildmanifest.json") manifest.updatepath(pathconfiguration) # This is needed so as to allow path scheme to be changed depending on installer format for category, source, target on manifest.iterfiles(): # simple case is copying source to target, potentially using the category label for category specific stuff. This was enough for me to do straight install, eggs, .exe and .msi windows installers and .mpkg from that with a relatively simple API. Bonus point, if you include this file inside the installers, you can actually losslessly convert from one to the other.

I think Donald's suggestion can be phrased as this: During build, copy the dist metadata (name, version, dependencies...) to the build manifest as well. Then allow to upload only the built versions for different platforms to PyPI etc. and allow relative anarchy to reign in how you create the built dists.

And I'm saying that would encourage a culture that's very dangerous from a security perspective. Even if many uses binaries, it is important to encourage a culture where it is always trivial (well, as trivial as we can possibly make it, in the case of Windows) to build from source for those who wish to.

Making the user-facing entry point of the dist metadata be in the source package rather than the binary package seems like a necessary (but not sufficient) condition for such a culture.

Dag

More information about the Python-Dev mailing list