On Fri, Jun 22, 2012 at 10:38 AM, Donald Stufft <donald.stufft@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. David