[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [GSoC] Rewriting tasks.py to exclusively use UDD


On Sun, Jun 28, 2015 at 05:02:11PM +0530, Akshita Jha wrote:
> I had almost completed rewriting blendstasktools.py to use UDD. I was
> testing it and making some changes and now I have got really confused. Can
> you please help me understand things a little better ?
> In tasks.py,
> -> 'tasks' object of class Tasks is created.
> -> class Tasks first reads the configuration file of the blend.
>     -> It has a function _InitMetapacakgekeys, which gets all the tasks
> inside the blend.
>        The query for this is :
>             query = "SELECT task FROM blends_tasks WHERE blend = '%s' ORDER
> BY task" % (self.blendname)
>     -> GetAllDependencies() gets the description and its translations of
> all the metapackages. Also, for each task an object of class
> TaskDependencies is created.     The __init__() of class TaskDependencies
> has:
>         self.dependencies = {}
>         for pkgstat in pkgstatus:
>             self.dependencies[pkgstat] = []
>     pkgstatus is a global dictionary and has keys like
> official_high,official_low..... etc. How can I get the status of the
> dependencies from UDD ?

Official_high are those packages that are declared Depends (or Recommends
which is technically identical) and official_low are packages that are only
suggested.  This is kept in the depends field.  For instance you get all
official_low packages of Blend Debian Med in task bio by

udd=# select * from blends_dependencies where blend = 'debian-med' and task = 'bio' and dependency = 's' ; 

When using ... dependency = 'd' you get the official_high packages.
>     -> SetMetapkgInfo() in class TaskDependencies, creates an object of
> class DependantPackage. Class DependantPackage holds all the possible
> information of a package.

I can not find a question here - sooo ... I agree.
>     -> GetTaskDependencies() in class TaskDependencies, used to read the
> task files and get all the information. Rewriting it to use UDD, involves
> the following queries:
>         # Get the title and description of each task in a blend
>         # Title
>         query = "SELECT title FROM blends_tasks WHERE task='%s' AND
> blend='%s'" % (self.task, self.blendname)
>         # Description
>         query = "SELECT description, long_description FROM blends_tasks
> WHERE task='%s' AND blend='%s'" % (self.task, self.blendname)
>         # Get the package_name, description, homepage, maintainer of the
> official dependencies of the task
>         query = "SELECT DISTINCT b.package, p.description, p.homepage,
> p.maintainer_name, p.maintainer_email \
>                 FROM blends_dependencies b JOIN packages p ON
> p.package=b.package \
>                 WHERE b.blend='%s' AND b.task='%s'" % (self.blendname,
> self.task)
>         _execute_udd_query(query)
>         if curs.rowcount > 0:
>             dep_info = curs.fetchall()
>             for each_dep in dep_info:
>                 self.metadepends = each_dep[0]
>                 dep = DependantPackage(self.blendname, self.task)
>                 dep.why = each_dep[1]
>                 _name = each_dep[3]
>                 _url = each_dep[4]
>                 dep.responsible = '<a href="mailto:%s";>%s</a>' % (_url,
> _name)
>                 dep.pkg = each_dep[0]
>                 dep.properties['homepage'] = each_dep[2]
>         What is the difference between self.metadepends and dep.pkg ? Due
> to my negligency, I had not paid attention to this before and I have made a
> major mistake throughout.

Metadepends ist *NOT* *YET* implemented.  The idea was to "resolve"
depenmdencies contained in a metapackage.  Imagine for instance the
Debian Science task biology.  It could depend from med-bio and
med-bio-dev.  For the tasks pages it is not very nice to just display
these two entries as metapackages but rather all the dependant packages
contained in med-bio and med-bio-dev.  Since this is not yet implemented
in the current web sentinel I suggest to ignore this for the moment.  So
feel free to simply skip self.metadepends.  Once we can reproduce the
current tasks pages I think it is pretty simple to "resolve" the
metapackage dependencies by an UDD query (which would have been a
nuisance in the current way where you would have to read several tasks
files from other Blends (with probably different VCSes).
>         #Get the package_name, description, homepage, maintainer, vcs,
> wnpp, section, license of the prospective dependencies of the task
>         query = "SELECT DISTINCT bp.package, bp.maintainer, bp.homepage,
> bp.description, bp.long_description, \
>                 bp.vcs_type, bp.vcs_url, bp.vcs_browser, bp.section,
> bp.license, bp.wnpp, bp.wnpp_type, bp.wnpp_desc \
>                 FROM blends_prospectivepackages bp JOIN blends_dependencies
> b ON b.blend=bp.blend \
>                 WHERE bp.blend='%s' and b.task='%s'" % (self.blendname,
> self.task)
>         _execute_udd_query(query)
>         if curs.rowcount > 0:
>             pros_info = curs.fetchall()
>             for each_pros in pros_info:
>                 dep.pkg = each_pros[0]
>                 dep.properties['homepage'] = each_pros[2]
>                 dep.desc['en']['short'] = each_pros[3]
>                 dep.desc['en']['long'] = each_pros[4]
>                 dep.properties['vcs_type'] = each_pros[5]
>                 dep.properties['vcs_url'] = each_pros[6]
>                 dep.properties['vcs_browser'] = each_pros[7]
>                 dep.properties['section'] = each_pros[8]
>                 dep.properties['license'] = each_pros[9]
>                 dep.properties['wnpp'] = each_pros[10]
>         The earlier code also had language,

IMHO we can ignore language.  This field is never really used.  I was
inspired by the fields asked for when issing an "Intent To Package" bug.
I several times thought about droping this.

> registartion, pkg-url
> remark(short, long) fields. From where in UDD, can I get the language of a
> package ?

This is not yet in UDD.  Lets ignore this for the moment.  We need to
add this information to the tasks file parser and add it to UDD.  I
think it is better if you work straightforward with the important stuff
and we care for this less important things later.

> I am aware that the UDD has to be enhanced to include the
> registration field. Where do I get pkg-url, pkg-status, remark from?

The latter are also in the tasks files as an optional field.

>         Also, there is usage of a field_obsolete list. What exactly is
> stored in this ?

? I do not remember this. :-(

> I'll ask doubts regarding the rest of the code, once I have clealy
> rewritten the code upto this point.

Feel free to ask any question you might face and ask again if my answers
might not be fully clear.

Kind regards



Reply to: