On 06/22/2012 12:20 PM, David Cournapeau wrote:
On Fri, Jun 22, 2012 at 10:38 AM, Donald Stufft<donald.stu...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
