On Tue, Dec 22, 2009 at 11:06 AM, Tarek Ziadé <[email protected]> wrote:
> If you are referring to the installation format, Distribute wants to > drop any extra format in the future and stick with a unique, standard > format described in PEP 376 to avoid having an heterogeneous > site-packages. Does that mean that eggs would be "deprecated" ? > I like the idea Cool :) Here is what I got so far. I have my small own packaging solution, and a small utility called toymaker, which works as steps (toymaker configure, toymaker build, etc...). For this discussion, the only thing to know is that toymaker build produces this build manifest, and both toymaker install/build_egg read this build manifest to produce the install target. Right now, the format I use is ad-hoc, what matters at this point is the information it describes, and anything is open to changes if anyone has a better idea on a particular point. There are three sections: - A copy of PKG-INFO data in a simple form for easy parsing - A variable section, containing paths (bindir, libdir, etc..) and executables - A files section, which contains subsections of files to install. For example, for sphinx, toymaker build produces this name=Sphinx license=BSD author=Georg Brandl url=http://sphinx.pocoo.org/ top_levels=sphinx download_url=http://pypi.python.org/pypi/Sphinx summary=Python documentation generator [email protected] version=0.6.3 platforms=any install_requires=Pygments>=0.8 install_requires=Jinja2>=2.1 install_requires=docutils>=0.4 classifiers=Development Status :: 4 - Beta classifiers=Environment :: Console classifiers=Environment :: Web Environment classifiers=Intended Audience :: Developers classifiers=License :: OSI Approved :: BSD License classifiers=Operating System :: OS Independent classifiers=Programming Language :: Python classifiers=Topic :: Documentation classifiers=Topic :: Utilities description=Sphinx is a tool that makes it easy to create intelligent and beautiful description=documentation for Python projects (or other documents consisting of description=multiple reStructuredText sources), written by Georg Brandl. description=It was originally created to translate the new Python documentation, description=but has now been cleaned up in the hope that it will be useful to many description=other projects. description= description=Sphinx uses reStructuredText as its markup language, and many of its strengths description=come from the power and straightforwardness of reStructuredText and its description=parsing and translating suite, the Docutils. description= description=Although it is still under constant development, the following features description=are already present, work fine and can be seen "in action" in the Python docs: description= description=* Output formats: HTML (including Windows HTML Help), plain text and LaTeX, description= for printable PDF versions description=* Extensive cross-references: semantic markup and automatic links description= for functions, classes, glossary terms and similar pieces of information description=* Hierarchical structure: easy definition of a document tree, with automatic description= links to siblings, parents and children description=* Automatic indices: general index as well as a module index description=* Code handling: automatic highlighting using the Pygments highlighter description=* Various extensions are available, e.g. for automatic testing of snippets description= and inclusion of appropriately formatted docstrings. description= description=A development egg can be found `here description=<http://bitbucket.org/birkenfeld/sphinx/get/tip.gz#egg=Sphinx-dev>`_. !- VARIABLES paths pkgname=Sphinx datarootdir=$prefix/share eprefix=$prefix sitedir=$libdir/python$py_version_short/site-packages libdir=$eprefix/lib prefix=/usr/local py_version_short=2.6 gendatadir=$sitedir datadir=$datarootdir includedir=$prefix/include sbindir=$eprefix/sbin pkgdatadir=$datadir/$pkgname bindir=$eprefix/bin mandir=$datarootdir/man executables sphinx-build=sphinx:main sphinx-quickstart=sphinx.quickstart:main sphinx-autogen=sphinx.ext.autosummary.generate:main !- FILELIST executables:sphinx-build srcdir=build/scripts-2.6 target=$bindir sphinx-build executables:sphinx-quickstart srcdir=build/scripts-2.6 target=$bindir sphinx-quickstart executables:sphinx-autogen srcdir=build/scripts-2.6 target=$bindir sphinx-autogen datafiles:gendata_sphinx_locale ... The file contains just enough data to build egg and install on disk ATM, and I include the build manifest in the produced egg so that conversion to wininst-based (or other types of) installers is possible. For the file list, each section has the same structure: - type:name -> type would be used for post-install (byte compile python files, chmod binaries, etc...), name is not really important, but it enables having several subsections of the same type (so that different target/srcdir are possible) - the next two lines are srcdir and target: target can be a variable as defined in the path section (this is important to "relocate" installs in some cases), srcdir is such as every file of the section can be found in srcdir/file. Although I have not thought about the problem yet, it should also be usable for uninstall, and for on-disk query of installed packages. I should note at this point that it is mostly a rip-off of one concept in cabal I really like, the installed package information, which is used for those purposes as well: http://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distribution-InstalledPackageInfo.html > Distribute 0.7 is still under heavy construction, and the goals we have > about the installation features are not fully defined yet. What we want for > sure is to make it the laboratory of Distutils to improve things in smaller > cycles than python. And having a better build description sounds like > something we could use/have. I could start implementing it within distutils/Distribute, at least for the parts which I guess will be the least controversial (the FILE section and the path variables), and specify the exact file format. I think it should be possible for the install command of distribute to only rely on this file - this would actually be a good test, comparing installs with the old and the new way. David _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
