[Python-Dev] Status of packaging in 3.3

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.from_file("build_manifest.json")
> manifest.update_path(path_configuration) # This is needed so as to
> allow path scheme to be changed depending on installer format
> for category, source, target on manifest.iter_files():
>       # 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