On Fri, Mar 25, 2011 at 12:04:29PM +0100, Patrick Schoenfeld wrote: > Hi Julian, > > On Fri, Mar 25, 2011 at 11:21:02AM +0100, Julian Andres Klode wrote: > > On Fri, Mar 25, 2011 at 10:57:03AM +0100, Patrick Schoenfeld wrote: > > > Package: python-apt > > > Severity: wishlist > > > > > > Hi, > > > > > > currently the python-apt bindings for the apt package cache do not > > > provide access to the task associated with a package. I have a use-case > > > where I need it. > > > > > > The information can be gathered from the Packages file, > > > where for each Package, which is a member of a task, a key-value pair > > > "Task: foo" is stored. > > > > > > It would be nice if python-apt provided a method task > > > in apt.packagePackage() objects. Apart from this it would be nice to > > > have functions in the cache object to access list of tasks and > > > associated packages.. > > > > Use Version.record["Task"].split(): > > thanks for showing me a way to get that information, > as I would have never found that myself. > > > > >>> import apt > > >>> apt.Cache()["gnome"].candidate.record["Task"].split() > > ['gnome-desktop'] > > > > The tasks are not in the cache, and this is easy enough, so > > I don't think we need an extra method for it. > > Well, easy enough is an interesting term in that case. Maybe > documentation could be improved, because its very hard to get to that > information if you did not write the API yourself. I mainly worked on the low-level documentation. The apt_pkg and apt_inst modules are much better documented. They are actually documented twice, once for pydoc and once for the online documentation, the latter including examples and stuff like this. > From documentation and my apt understanding I could get as far to > understand that each package has a (installation) candidate > with all package-version-specific informations associated to it. > > API doc says: > "Return the candidate version of the package" > > It takes something to understand that formulation like you eventually > meant it. > I suggest the following wording to make it more accurate and better > understandable: > > "Return the candidate of the package as a Version() object, which stores > all information about the candidate version." > > This probably gives a hint, that it does not only return "1.0.0-1" in an > object representation but all data associated to the given candidate. Yes. Once we get rid of Python 2 (or convert from 3 to 2), we can also add annotations. > > Now to the Version() class: > The docstring reads as: > "Representation of a package version" > > Yes, if you already know the API or if you are good at guessing, its > clear what this one sentence means. A short introduction whats possible > with the module would be nice though. > > Maybe something like: > > """ > Representation of a package version > > This class representates a package version and provides access to all > version-specific package attributes. > """ The low-level class uses: "The version object contains all information related to a specific package version." (in the Sphinx-powered documentation) > > Now, if one is so far to get to the point of having a Version() object, > where to go from there? > This object does have all kind of property accessors, but none for the > task field of the candidate version of the package. > > Just as a sidenote: This would be a good point to have a "def task()" > which would return the task associated to that candidate version. > I know you think using records()["Task"] is "easy enough", but OTOH it > would be "easy enough" to access the Priority of the given candver by > this means as well. Nevertheless you provide a priority function for it. Priority is stored in the cache and frequently used. Most of the other properties are there because they exist in apt_pkg.PackageRecords or apt_pkg.Version. http://apt.alioth.debian.org/python-apt-doc/library/apt_pkg.html#apt_pkg.PackageRecords > > Now there is records(), which is nice, but again, by its documentation > its not reall obvious that it can lead to the answer you gave: > > "Return a Record() object for this version" > > Suggestion: > "Return a Record() object for this version, which provides access > to the raw attributes of the candidate version" Sounds good. > > Last but not least the Record() class: > """ > Represent a pkgRecord > > It can be access liked a dict.. > > """ > > This could be easily improved by writing: > > "Represent a package record as stored in the Packages file" One great example were the low-level is much better documented: http://apt.alioth.debian.org/python-apt-doc/library/apt_pkg.html#apt_pkg.PackageRecords "Provide further information about the packages in the Cache object cache. This efficiently parses the package files to provide information not available in the cache, such as maintainer, hash sums, description, and the file name of the package. It also provides the complete record of the package" -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Attachment:
pgpH2sRyIPdGP.pgp
Description: PGP signature