Re: [GSoC] Rewriting tasks.py to exclusively use UDD
Hi,
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
Andreas.
--
http://fam-tille.de
Reply to: