commit: e77fc9ed91def889db3627f485d2af24afb9d118 Author: Jauhien Piatlicki <jauhien <AT> gentoo <DOT> org> AuthorDate: Mon Apr 20 12:12:30 2015 +0000 Commit: Jauhien Piatlicki <jauhien <AT> gentoo <DOT> org> CommitDate: Mon Apr 20 21:12:58 2015 +0000 URL: https://gitweb.gentoo.org/proj/g-sorcery.git/commit/?id=e77fc9ed
[docs] update documentation docs/developer_instructions.html | 130 +++++++++++++++++++++++++++------- docs/developer_instructions.rst | 149 ++++++++++++++++++++++++++++----------- docs/g-sorcery.8 | 10 +-- docs/g-sorcery.8.rst | 10 +-- docs/g-sorcery.cfg.8 | 8 +-- docs/g-sorcery.cfg.8.rst | 6 +- g_sorcery/ebuild.py | 28 ++++---- g_sorcery/metadata.py | 24 +++---- g_sorcery/package_db.py | 6 +- 9 files changed, 260 insertions(+), 111 deletions(-) diff --git a/docs/developer_instructions.html b/docs/developer_instructions.html index f4e89ab..4cea319 100644 --- a/docs/developer_instructions.html +++ b/docs/developer_instructions.html @@ -3,13 +3,13 @@ <html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> -<meta name="generator" content="Docutils 0.10: http://docutils.sourceforge.net/"; /> +<meta name="generator" content="Docutils 0.12: http://docutils.sourceforge.net/"; /> <title>Developer Instructions</title> <style type="text/css"> /* :Author: David Goodger ([email protected]) -:Id: $Id: html4css1.css 7514 2012-09-14 14:27:12Z milde $ +:Id: $Id: html4css1.css 7614 2013-02-21 15:55:51Z milde $ :Copyright: This stylesheet has been placed in the public domain. Default cascading style sheet for the HTML output of Docutils. @@ -313,6 +313,21 @@ table.docutils th.field-name, table.docinfo th.docinfo-name { white-space: nowrap ; padding-left: 0 } +/* "booktabs" style (no vertical lines) */ +table.docutils.booktabs { + border: 0px; + border-top: 2px solid; + border-bottom: 2px solid; + border-collapse: collapse; +} +table.docutils.booktabs * { + border: 0px; +} +table.docutils.booktabs th { + border-bottom: thin solid; + text-align: left; +} + h1 tt.docutils, h2 tt.docutils, h3 tt.docutils, h4 tt.docutils, h5 tt.docutils, h6 tt.docutils { font-size: 100% } @@ -412,7 +427,7 @@ Then available packages can be installed as usual <strong>Gentoo</strong> packag </ul> <p>There are two ways of using backend:</p> <ul class="simple"> -<li>run it as a CLI tool manually</li> +<li>run it as a CLI tool manually (not recommended)</li> <li>use its integration with layman</li> </ul> </div> @@ -443,7 +458,7 @@ or derived class.</p> side: generate the entire overlay tree (possibly by layman) or generate a given ebuild and its dependencies. In a first case it would be very bad idea to have sources in ebuild's SRC_URI as during manifest generation for an overlay all the sources would be downloaded -to the user's comuter that inevitably would made user really happy. So one ebuild generator +to the user's computer that inevitably would made user really happy. So one ebuild generator generates ebuild with empty SRC_URI. Note that a mechanism for downloading of sources during ebuild merging should be provided. For an example see <strong>git-2</strong> eclass from the main tree or any eclass from backends provided with g-sorcery if you want to implement such a mechanism or @@ -513,8 +528,19 @@ contains a list of overlays this repository depends on. If present it should con </div> <div class="section" id="package-database"> <h1>Package database</h1> -<div class="section" id="directory-layout"> -<h2>Directory layout</h2> +<p>The package is an in memory structure that describes available +packages and to this structure corresponding files layout.</p> +<div class="section" id="directory-layout-versions"> +<h2>Directory layout versions</h2> +<p>There are two directory layouts at the moment:</p> +<ul class="simple"> +<li>v.0 legacy layout</li> +<li>v.1 layout that supports different DB structure versions and +different file formats.</li> +</ul> +</div> +<div class="section" id="v-0-legacy-layout"> +<h2>v.0 legacy layout</h2> <p>Package database is a directory tree with JSON files. The layout of this tree looks like:</p> <pre class="code literal-block"> db dir @@ -526,30 +552,74 @@ db dir ... </pre> </div> +<div class="section" id="v-1-layout"> +<h2>v.1 layout</h2> +<p>Metadata file contains information about layout and DB versions as +well as information about file format used to store packages +information. At the moment JSON and BSON are supported.</p> +<pre class="code literal-block"> +db dir + manifest.json: database manifest + categories.json: information about categories + metadata.json: DB metadata + category1 + packages.[b|j]son: information about available packages + category2 + ... +</pre> +</div> +<div class="section" id="database-structure-versions"> +<h2>Database structure versions</h2> +<p>Database structure has two versions: legacy v.0 and v.1. With +directory layout v.0 only DB structure v.0 is supported. DB structure +is internal and shouldn't be relied on by any external tools (including +backends). PackageDB class API should be used instead.</p> +</div> <div class="section" id="packagedb-class"> <h2>PackageDB class</h2> <p>PackageDB class is aimed for interaction with package database. It has methods that allow to add categories and packages and to do queries on them. Usually you do not want to customize this -class. But in case you want there is number of methods that can be redifend.</p> -<p>First of all if you have a database that should be synced with another already generate database +class.</p> +<p>If you have a database that should be synced with another already generate database you can redifine URI to be used for syncing using <strong>get_real_db_uri</strong> method.</p> -<p>There is a number of hooks that are called after package, category or the whole database is -written/read:</p> -<ul class="simple"> -<li>additional_write_version</li> -<li>additional_write_package</li> -<li>additional_write_category</li> -<li>additional_write</li> -<li>additional_read_version</li> -<li>additional_read_package</li> -<li>additional_read_category</li> -<li>additional_read</li> -</ul> <p>Note that before add any package you should add a category for it using <strong>add_category</strong>. Then packages can be added using <strong>add_package</strong>. PackageDB currently does not write changes -automatically, so you should call <strong>write_and_manifest</strong> after changes are done. This is not relevant +automatically, so you should call <strong>write</strong> after changes are done. This is not relevant for database changing in <strong>process_data</strong> method of database generator as there all changes -are written by other methods it calls internally after <strong>process_data</strong>.</p> +are written by other methods it calls internally after +<strong>process_data</strong>.</p> +<p>If you have some fields that are common to all ebuilds in a given +category, it's better to split them to common data, that can be set for +category. This data will be added to ebuild data in results of package +queries automatically.</p> +<p>Public API that should be used for manipulating packages data:</p> +<ul class="simple"> +<li>add_category(self, category, description=None) -- add new category.</li> +<li>set_common_data(self, category, common_data) -- set common ebuild +data for a category.</li> +<li>get_common_data(self, category) -- get common ebuild data for a +category.</li> +<li>add_package(self, package, ebuild_data=None) -- add new packages +(characterized by category, package name and version) with given +ebuild data.</li> +<li>list_categories(self) -- list categories.</li> +<li>in_category(self, category, name) -- test whether a package is in a +given category.</li> +<li>list_package_names(self, category) -- list package names in a +category.</li> +<li>list_catpkg_names(self) -- list category/package name.</li> +<li>list_package_versions(self, category, name) -- list package +versions.</li> +<li>list_all_packages(self) -- list all packages.</li> +<li>get_package_description(self, package) -- get ebuild data (it +returns a dict that contains both ebuild data for a given package +and fields from common data for a given category).</li> +<li>get_max_version(self, category, name) -- get the recent available +version of a package.</li> +<li>iterator -- PackageDB class defines an iterator that iterates +through all available package/ebuild data pairs.</li> +</ul> +<p>To see description of these methods look in g_sorcery/package_db.py file.</p> </div> <div class="section" id="json-serializable-objects"> <h2>JSON serializable objects</h2> @@ -561,6 +631,7 @@ json module</li> <li>class method <strong>deserialize</strong> that takes a value returned by <strong>serialize</strong> and constructs new instance of your class using it</li> </ul> +<p>This holds true for other supported file formats (BSON at the moment).</p> </div> <div class="section" id="dependency-handling"> <h2>Dependency handling</h2> @@ -633,6 +704,15 @@ already downloaded and parsed data.</p> </li> </ul> <p>Generally speaking these are all the method you should implement.</p> +<p>Both PackageDB and DBGenerator constructors accept these fields that +are used to control preferred DB version/layout and file format (used +during writing DB to disk):</p> +<ul class="simple"> +<li>preferred_layout_version, 1 by default</li> +<li>preferred_db_version, 1 by default</li> +<li>preferred_category_format, json by default</li> +</ul> +<p>To see how to use them look at the gs-pypi backend.</p> </div> <div class="section" id="value-convertion"> <h2>Value convertion</h2> @@ -943,8 +1023,10 @@ that quacks like this class.</p> <p>Before doing it you should have defined classes you pass to it as parameters. They should be database generator, two ebuild generators, eclass and metadata generators.</p> <p>Also you should write an executable that calls g-sorcery and some configs.</p> -<p>To have better understanding you can look at gs-elpa and gs-pypi backends available -in g-sorcery repository. Also available tests could be usefull.</p> +<p>To have better understanding you can look at +gs-elpa (<a class="reference external" href="https://github.com/jauhien/gs-elpa";>https://github.com/jauhien/gs-elpa</a>) and gs-pypi +(<a class="reference external" href="https://github.com/jauhien/gs-pypi";>https://github.com/jauhien/gs-pypi</a>) backends. Also available tests +could be usefull.</p> <p>Note that there is a tool for editing generated database named <strong>gs-db-tool</strong>.</p> </div> </div> diff --git a/docs/developer_instructions.rst b/docs/developer_instructions.rst index de266b9..f0667ea 100644 --- a/docs/developer_instructions.rst +++ b/docs/developer_instructions.rst @@ -66,7 +66,7 @@ So there are two phases of backend operation: There are two ways of using backend: -- run it as a CLI tool manually +- run it as a CLI tool manually (not recommended) - use its integration with layman @@ -109,7 +109,7 @@ There are two ebuild generator classes as there are two scenarios of using backe side: generate the entire overlay tree (possibly by layman) or generate a given ebuild and its dependencies. In a first case it would be very bad idea to have sources in ebuild's SRC_URI as during manifest generation for an overlay all the sources would be downloaded -to the user's comuter that inevitably would made user really happy. So one ebuild generator +to the user's computer that inevitably would made user really happy. So one ebuild generator generates ebuild with empty SRC_URI. Note that a mechanism for downloading of sources during ebuild merging should be provided. For an example see **git-2** eclass from the main tree or any eclass from backends provided with g-sorcery if you want to implement such a mechanism or @@ -134,7 +134,7 @@ A binary should just pass arguments to g-sorcery. For a backend named gs-elpa it #!/bin/bash - g-sorcery g-elpa $@ + g-sorcery g-elpa $@ Backend config ~~~~~~~~~~~~~~ @@ -162,15 +162,15 @@ A simple backend config: .. code-block:: { - "package": "gs_elpa", + "package": "gs_elpa", "repositories": { "gnu-elpa": { "repo_uri": "http://elpa.gnu.org/packages/"; - }, + }, "marmalade": { "repo_uri": "http://marmalade-repo.org/packages/";, "masters": ["gentoo", "gnu-elpa"] - }, + }, "melpa": { "repo_uri": "http://melpa.milkbox.net/packages/";, "masters": ["gentoo", "gnu-elpa"] @@ -181,8 +181,20 @@ A simple backend config: Package database ================ -Directory layout -~~~~~~~~~~~~~~~~ +The package is an in memory structure that describes available +packages and to this structure corresponding files layout. + +Directory layout versions +~~~~~~~~~~~~~~~~~~~~~~~~~ + +There are two directory layouts at the moment: + +* v.0 legacy layout +* v.1 layout that supports different DB structure versions and + different file formats. + +v.0 legacy layout +~~~~~~~~~~~~~~~~~ Package database is a directory tree with JSON files. The layout of this tree looks like: @@ -196,41 +208,82 @@ Package database is a directory tree with JSON files. The layout of this tree lo category2 ... +v.1 layout +~~~~~~~~~~ -PackageDB class -~~~~~~~~~~~~~~~ - -PackageDB class is aimed for interaction with package database. It has methods that allow -to add categories and packages and to do queries on them. Usually you do not want to customize this -class. But in case you want there is number of methods that can be redifend. - -First of all if you have a database that should be synced with another already generate database -you can redifine URI to be used for syncing using **get_real_db_uri** method. - -There is a number of hooks that are called after package, category or the whole database is -written/read: - -* additional_write_version +Metadata file contains information about layout and DB versions as +well as information about file format used to store packages +information. At the moment JSON and BSON are supported. -* additional_write_package +.. code-block:: -* additional_write_category + db dir + manifest.json: database manifest + categories.json: information about categories + metadata.json: DB metadata + category1 + packages.[b|j]son: information about available packages + category2 + ... -* additional_write +Database structure versions +~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* additional_read_version +Database structure has two versions: legacy v.0 and v.1. With +directory layout v.0 only DB structure v.0 is supported. DB structure +is internal and shouldn't be relied on by any external tools (including +backends). PackageDB class API should be used instead. -* additional_read_package +PackageDB class +~~~~~~~~~~~~~~~ -* additional_read_category +PackageDB class is aimed for interaction with package database. It has methods that allow +to add categories and packages and to do queries on them. Usually you do not want to customize this +class. -* additional_read +If you have a database that should be synced with another already generate database +you can redifine URI to be used for syncing using **get_real_db_uri** method. Note that before add any package you should add a category for it using **add_category**. Then packages can be added using **add_package**. PackageDB currently does not write changes -automatically, so you should call **write_and_manifest** after changes are done. This is not relevant +automatically, so you should call **write** after changes are done. This is not relevant for database changing in **process_data** method of database generator as there all changes -are written by other methods it calls internally after **process_data**. +are written by other methods it calls internally after +**process_data**. + +If you have some fields that are common to all ebuilds in a given +category, it's better to split them to common data, that can be set for +category. This data will be added to ebuild data in results of package +queries automatically. + +Public API that should be used for manipulating packages data: + +* add_category(self, category, description=None) -- add new category. +* set_common_data(self, category, common_data) -- set common ebuild + data for a category. +* get_common_data(self, category) -- get common ebuild data for a + category. +* add_package(self, package, ebuild_data=None) -- add new packages + (characterized by category, package name and version) with given + ebuild data. +* list_categories(self) -- list categories. +* in_category(self, category, name) -- test whether a package is in a + given category. +* list_package_names(self, category) -- list package names in a + category. +* list_catpkg_names(self) -- list category/package name. +* list_package_versions(self, category, name) -- list package + versions. +* list_all_packages(self) -- list all packages. +* get_package_description(self, package) -- get ebuild data (it + returns a dict that contains both ebuild data for a given package + and fields from common data for a given category). +* get_max_version(self, category, name) -- get the recent available + version of a package. +* iterator -- PackageDB class defines an iterator that iterates + through all available package/ebuild data pairs. + +To see description of these methods look in g_sorcery/package_db.py file. JSON serializable objects ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -244,6 +297,8 @@ g_sorcery.serialization module. It means it should define two methods: * class method **deserialize** that takes a value returned by **serialize** and constructs new instance of your class using it +This holds true for other supported file formats (BSON at the moment). + Dependency handling ~~~~~~~~~~~~~~~~~~~ @@ -295,11 +350,11 @@ With this aim you should subclass it and define some methods. Here they are: - open_file: Whether parser accepts file objects. - open_mode: Open mode for a downloaded file. - + The only mandatory entry is uri. The default implementation returns [backend_config["repositories"][REPOSITORY]["repo_uri"]]. - + * parse_data This method parses a file downloaded from a repository and returns its content in any form you think useful. @@ -311,6 +366,16 @@ With this aim you should subclass it and define some methods. Here they are: Generally speaking these are all the method you should implement. +Both PackageDB and DBGenerator constructors accept these fields that +are used to control preferred DB version/layout and file format (used +during writing DB to disk): + +* preferred_layout_version, 1 by default +* preferred_db_version, 1 by default +* preferred_category_format, json by default + +To see how to use them look at the gs-pypi backend. + Value convertion ~~~~~~~~~~~~~~~~ @@ -388,7 +453,7 @@ is a recommended one. To use it you should inherit it and define an ebuild layou Layout has entries for vars and inherited eclasses. Each entry is a list. Entries are processed in the following order: - + * vars_before_inherit * inherit @@ -414,7 +479,7 @@ Variable names are automatically transformed to the upper-case during ebuild gen An example of ebuild generator: .. code-block:: - + Layout = collections.namedtuple("Layout", ["vars_before_inherit", "inherit", "vars_after_description", "vars_after_keywords"]) @@ -429,7 +494,7 @@ An example of ebuild generator: ["repo_uri", "source_type", "realname"] inherit = ["g-elpa"] - + vars_after_description = \ ["homepage"] @@ -497,7 +562,7 @@ Metadata XML schema looks like 'multiple' : (True, ""), 'required' : False, 'subtags' : []}, - + {'name' : 'maintainer', 'multiple' : (True, ""), 'required' : False, @@ -520,7 +585,7 @@ Metadata XML schema looks like 'multiple' : (False, ""), 'required' : False, 'subtags' : []}, - + {'name' : 'use', 'multiple' : (False, ""), 'required' : False, @@ -529,7 +594,7 @@ Metadata XML schema looks like 'required' : True, 'subtags' : []}] }, - + {'name' : 'upstream', 'multiple' : (False, ""), 'required' : False, @@ -634,7 +699,9 @@ generator, two ebuild generators, eclass and metadata generators. Also you should write an executable that calls g-sorcery and some configs. -To have better understanding you can look at gs-elpa and gs-pypi backends available -in g-sorcery repository. Also available tests could be usefull. +To have better understanding you can look at +gs-elpa (https://github.com/jauhien/gs-elpa) and gs-pypi +(https://github.com/jauhien/gs-pypi) backends. Also available tests +could be usefull. Note that there is a tool for editing generated database named **gs-db-tool**. diff --git a/docs/g-sorcery.8 b/docs/g-sorcery.8 index 1d2f353..6782c98 100644 --- a/docs/g-sorcery.8 +++ b/docs/g-sorcery.8 @@ -1,6 +1,6 @@ .\" Man page generated from reStructuredText. . -.TH G-SORCERY 8 "2014-05-10" "0.1" "g-sorcery" +.TH G-SORCERY 8 "2015-04-20" "0.2" "g-sorcery" .SH NAME g-sorcery \- manage overlays for 3rd party software providers . @@ -65,11 +65,11 @@ use it with \fBlayman\fP In this case all you need to do is install \fBlayman\-9999\fP, \fBg\-sorcery\fP and appropriate backend. Then you should just run \fIlayman \-L\fP as root and find an overlay you want. Type of overlay will be -displayed as \fIg\-sorcery\fP. Then you add this overlay as +displayed as \fIg\-sorcery\fP\&. Then you add this overlay as usual. It\(aqs all you need to do and it\(aqs the recommended way of using \fBg\-sorcery\fP and backends. .IP \(bu 2 -use it as stand\-alone tool +use it as stand\-alone tool (not recommended) .sp In this case you should create an overlay (see \fBportage\fP documentation), sync it and populate it with one or more ebuilds. Then ebuilds could be installed by emerge or by \fBg\-sorcery\fP tool @@ -123,7 +123,7 @@ Backend configs. .SH NOTES .INDENT 0.0 .IP 1. 3 -At the moment the only package mangler \fBg\-sorcery\fP supports is \fBportage\fP. +At the moment the only package mangler \fBg\-sorcery\fP supports is \fBportage\fP\&. .UNINDENT .SH SEE ALSO .sp @@ -133,6 +133,6 @@ Written by Jauhien Piatlicki <[email protected]>. GSoC idea and mentorship by Rafael Martins. Lots of help and improvements by Brian Dolbec. Integration with layman based on work of Auke Booij. .SH COPYRIGHT -Copyright (c) 2013-2014 Jauhien Piatlicki, License: GPL-2 +Copyright (c) 2013-2015 Jauhien Piatlicki, License: GPL-2 .\" Generated by docutils manpage writer. . diff --git a/docs/g-sorcery.8.rst b/docs/g-sorcery.8.rst index 86f7e66..1e9af4e 100644 --- a/docs/g-sorcery.8.rst +++ b/docs/g-sorcery.8.rst @@ -9,9 +9,9 @@ manage overlays for 3rd party software providers :Author: Written by Jauhien Piatlicki <[email protected]>. GSoC idea and mentorship by Rafael Martins. Lots of help and improvements by Brian Dolbec. Integration with layman based on work of Auke Booij. -:Date: 2014-05-10 -:Copyright: Copyright (c) 2013-2014 Jauhien Piatlicki, License: GPL-2 -:Version: 0.1 +:Date: 2015-04-20 +:Copyright: Copyright (c) 2013-2015 Jauhien Piatlicki, License: GPL-2 +:Version: 0.2 :Manual section: 8 :Manual group: g-sorcery @@ -54,8 +54,8 @@ There are two ways of using **g-sorcery**: displayed as *g-sorcery*. Then you add this overlay as usual. It's all you need to do and it's the recommended way of using **g-sorcery** and backends. - - * use it as stand-alone tool + + * use it as stand-alone tool (not recommended) In this case you should create an overlay (see **portage** documentation), sync it and populate it with one or more ebuilds. Then ebuilds could be installed by emerge or by **g-sorcery** tool diff --git a/docs/g-sorcery.cfg.8 b/docs/g-sorcery.cfg.8 index 9167c29..ea97ada 100644 --- a/docs/g-sorcery.cfg.8 +++ b/docs/g-sorcery.cfg.8 @@ -1,6 +1,6 @@ .\" Man page generated from reStructuredText. . -.TH G-SORCERY.CFG 8 "2014-05-10" "0.1" "g-sorcery" +.TH G-SORCERY.CFG 8 "2015-04-20" "0.2" "g-sorcery" .SH NAME g-sorcery.cfg \- custom settings for g-sorcery . @@ -39,8 +39,8 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] .SH SECTIONS AND VARIABLES .SS [main] .sp -Section with common settings. Contains only one variable: \fIpackage_manager\fP. -Currently it only can have value \fIportage\fP. +Section with common settings. Contains only one variable: \fIpackage_manager\fP\&. +Currently it only can have value \fIportage\fP\&. .SS [BACKEND] .sp Section with settings for a given backend. \fBBACKEND\fP should be a backend name. @@ -69,6 +69,6 @@ Written by Jauhien Piatlicki <[email protected]>. GSoC idea and mentorship by Rafael Martins. Lots of help and improvements by Brian Dolbec. .SH COPYRIGHT -Copyright (c) 2013-2014 Jauhien Piatlicki, License: GPL-2 +Copyright (c) 2013-2015 Jauhien Piatlicki, License: GPL-2 .\" Generated by docutils manpage writer. . diff --git a/docs/g-sorcery.cfg.8.rst b/docs/g-sorcery.cfg.8.rst index 930b4db..f9b5aac 100644 --- a/docs/g-sorcery.cfg.8.rst +++ b/docs/g-sorcery.cfg.8.rst @@ -9,9 +9,9 @@ custom settings for g-sorcery :Author: Written by Jauhien Piatlicki <[email protected]>. GSoC idea and mentorship by Rafael Martins. Lots of help and improvements by Brian Dolbec. -:Date: 2014-05-10 -:Copyright: Copyright (c) 2013-2014 Jauhien Piatlicki, License: GPL-2 -:Version: 0.1 +:Date: 2015-04-20 +:Copyright: Copyright (c) 2013-2015 Jauhien Piatlicki, License: GPL-2 +:Version: 0.2 :Manual section: 8 :Manual group: g-sorcery diff --git a/g_sorcery/ebuild.py b/g_sorcery/ebuild.py index 31782f0..c7a60e1 100644 --- a/g_sorcery/ebuild.py +++ b/g_sorcery/ebuild.py @@ -4,10 +4,10 @@ """ ebuild.py ~~~~~~~~~~~~~ - + ebuild generation - - :copyright: (c) 2013 by Jauhien Piatlicki + + :copyright: (c) 2013-2015 by Jauhien Piatlicki :license: GPL-2, see LICENSE for more details. """ @@ -30,7 +30,7 @@ class EbuildGenerator(object): Generate an ebuild for a package. Args: - package: package_db.Package instance. + package: g_collections.Package instance. ebuild_data: Dictionary with ebuild data. Returns: @@ -79,15 +79,15 @@ class EbuildGenerator(object): error = "substitution failed in line '" + line + "': " + error raise DependencyError(error) result.append(line) - + return result - + def get_template(self, package, ebuild_data): """ Generate ebuild template. Should be overriden. Args: - package: package_db.Package instance. + package: g_collections.Package instance. ebuild_data: Dictionary with ebuild data. Returns: @@ -95,7 +95,7 @@ class EbuildGenerator(object): """ ebuild = [] return ebuild - + def postprocess(self, ebuild, ebuild_data): """ A hook for changing of a generated ebuild. @@ -122,7 +122,7 @@ class EbuildGeneratorFromFile(EbuildGenerator): Generate ebuild template. Args: - package: package_db.Package instance. + package: g_collections.Package instance. ebuild_data: Dictionary with ebuild data. Returns: @@ -138,9 +138,9 @@ class EbuildGeneratorFromFile(EbuildGenerator): def get_template_file(self, package, ebuild_data): """ Get template filename for a package. Should be overriden. - + Args: - package: package_db.Package instance. + package: g_collections.Package instance. ebuild_data: Dictionary with ebuild data. Returns: @@ -158,7 +158,7 @@ class DefaultEbuildGenerator(EbuildGenerator): Layout has entries for vars and inherited eclasses. Each entry is a list. Entries are processed in the following order: - + vars_before_inherit inherit vars_after_inherit @@ -212,7 +212,7 @@ class DefaultEbuildGenerator(EbuildGenerator): if hasattr(layout, "vars_after_keywords"): self._append_vars_to_template(layout.vars_after_keywords) self.template.append("") - + def _append_vars_to_template(self, variables): """ @@ -241,7 +241,7 @@ class DefaultEbuildGenerator(EbuildGenerator): Generate ebuild template. Args: - package: package_db.Package instance. + package: g_collections.Package instance. ebuild_data: Dictionary with ebuild data. Returns: diff --git a/g_sorcery/metadata.py b/g_sorcery/metadata.py index fb7cb37..b17600e 100644 --- a/g_sorcery/metadata.py +++ b/g_sorcery/metadata.py @@ -4,10 +4,10 @@ """ metadata.py ~~~~~~~~~~~ - + metadata generation - - :copyright: (c) 2013 by Jauhien Piatlicki + + :copyright: (c) 2013-2015 by Jauhien Piatlicki :license: GPL-2, see LICENSE for more details. """ @@ -70,7 +70,7 @@ class XMLGenerator(object): schema: XML schema. """ self.external = external - self.schema = schema + self.schema = schema def generate(self, values): """ @@ -110,7 +110,7 @@ class XMLGenerator(object): self.add_single_tag(root, name, tag, val, attr) else: self.add_single_tag(root, name, tag, value) - + def add_single_tag(self, root, name, tag, value, attr=None): """ Add a single tag. @@ -143,7 +143,7 @@ default_schema = [{'name' : 'herd', 'multiple' : (True, ""), 'required' : False, 'subtags' : []}, - + {'name' : 'maintainer', 'multiple' : (True, ""), 'required' : False, @@ -209,7 +209,7 @@ default_schema = [{'name' : 'herd', ] }, ] - + class MetadataGenerator(object): """ @@ -225,13 +225,13 @@ class MetadataGenerator(object): schema = default_schema self.package_db = package_db self.xmlg = XMLGenerator('pkgmetadata', schema) - + def generate(self, package): """ Generate metadata for a package. Args: - package: package_db.Package instance. + package: g_collections.Package instance. Returns: Metadata source as a list of strings. @@ -252,7 +252,7 @@ class MetadataGenerator(object): Generate metadata using values from a description. Args: - package: package_db.Package instance. + package: g_collections.Package instance. description: Package description (see package_db module). Returns: @@ -261,13 +261,13 @@ class MetadataGenerator(object): """ metadata = self.xmlg.generate(description) return metadata - + def postprocess(self, package, description, metadata): """ Postprocess generated metadata. Can be overrided. Args: - package: package_db.Package instance. + package: g_collections.Package instance. description: Package description (see package_db module). metadata: xml.etree.ElementTree.Element instance diff --git a/g_sorcery/package_db.py b/g_sorcery/package_db.py index 4c67fdc..a88474d 100644 --- a/g_sorcery/package_db.py +++ b/g_sorcery/package_db.py @@ -325,7 +325,7 @@ class PackageDB(object): Add a package. Args: - package: package_db.Package instance. + package: g_collections.Package instance. ebuild_data: Dictionary with package description. """ if not ebuild_data: @@ -439,7 +439,7 @@ class PackageDB(object): List all packages in a database. Returns: - List of package_db.Package instances. + List of g_collections.Package instances. """ result = [] for category, cat_data in self.database.items(): @@ -454,7 +454,7 @@ class PackageDB(object): Get package ebuild data. Args: - package: package_db.Package instance. + package: g_collections.Package instance. Returns: Dictionary with package ebuild data.
