Re: [GSoC] Rewriting tasks.py to exclusively use UDD
Hi Akshita,
On Sat, Jun 06, 2015 at 06:58:47PM +0530, Akshita Jha wrote:
> Hi,
>
> I have written the pseudo code for blendstasktools.py to use UDD. I have
> also started rewriting the actual code for blendstasktools.py.
Fine.
> Should I
> keep committing/pushing this partially written code to the repo ? Or is it
> better to complete rewriting the entire module and then commit the new file
> ?
Any commit to the master branch of the remote repository will be
automatically pulled by a cron job on blends.debian.{org,net} so we need
to make sure that we will not break the production system. Since I
would prefer to check and test your current work we have two options:
You create a new branch (gsoc, udd, whateveryouwant) or you choose a
temporary new name. WHen I started rewriting bugs.py I ave choosen
bugs_udd.py. The advantage of the later method is that you can test
both in parallel on the production systems if you also use a different
output directory as long as we are in development (.../tasks_udd or so)
If you consider the later as an advantage yourself than lets do it this
way. Otherwise you might like to convince me about a different branch
if you have some good reasons. :-)
> > Yes, this can be done (while the direct use of the config files in the
> > tasks pages creation would not really harm since it is in the same Git -
> > I was mainly concerned about the other Blends data).
>
> I have kept this in mind and am using the ReadConfig() directly for reading
> the <blend-name>.conf files.
Never change a running system. ;-)
> > There is a UDD gatherer that fetches the data from Git/SVN and moves the
> > (largest part of) the data into UDD. For a start we should use the data
> > available in this table, yes.
>
> So, FetchTaskFiles() will not be needed anymore. This function basically
> checkouts svn or git repo, creating a tasks or debian folder and storing
> all the checked out files here. This function then returns the path to the
> tasks directory. Since, we have to use UDD, we will not need to check out
> using svn or git. Am I right ?
Yes, you are right.
> > There are some extra data not yet imported into UDD which is:
> >
> > 1. prospective package data - here we should enhance the UDD gatherer
> > to take this over as well (but this has no priority in the first
> > stage)
>
> Noted.
>
> > 2. publication data - I have sent several warnings that specifying
> > publication data in the tasks files is deprecated and should be done
> > in debian/upstream/metadata of the packages in question. My opinion
> > is that we should rather *delete* these data from tasks files than
> > fiddling around with it. The publication data belong to a *package*
> > and not to a task and we should not help people undermining this
> > principle.
>
> So this means we will not be needing SetPublications() in class
> DependantPackage anymore.
Yes, that's my aim.
> > > 4. class DependantPackage holds information about a package that is in
> > > dependency list. In UDD, the table blends_prospectivepackages holds this
> > > information.
> >
> > Not only in blends_prospective packages but also in the packages and
> > new_packages. All tables have basically the same structure and contain
> > different "types" of dependencies: Those who can be resolved inside
> > Debian (=in packages ... the "green" section on the tasks pages), those
> > that will be resolved soon (=new_packages ... the yellow section below
> > the green one) and the blends_prospectivepackages which are only in VCS
> > (also in yellow). The "red" section on the tasks pages is currently not
> > in UDD and it is IMHO fine to ignore these for the moment. They can be
> > put into another structural equivalent table later.
>
> GetTaskDependencies() in class TaskDependency reads the tasks files and is
> parsed using deb822.Sources.iter_paragraphs(). Since, we donot have these
> task files anymore, as you already mentioned we will need to use the tables
> packages, new_packages and blends_prospectivepackages from UDD to obtain
> the data.
... and some joins to bibref etc.
> I have a couple of questions:
>
> 1. We are not checking out from svn or git anymore. All the information
> present in the tasks files in tasks folder is also availbale in UDD. But
> what about the debian folder that is created ?
The debian/ folder that is fetched for Blends that are maintained in SVN
contains some metadata that should be in UDD as well. Please have a
short look into the code what exactly is used - I'm to lazy to do this
in my vacation. :-)
> 2. One of the files in debian folder is control.stub which is used in
> blend-get-names to obtain prefix of a metapackage in a blend. Wyy do we
> need blend-get-names to get the prefix? Can't we just use something like
> "prefix = blendname.split('-')[1] + '-' " as the prefix for :
> i) debian-science -> science-
> ii) debian-junior -> junior-
> iii) debian-ezgo -> ezgo-
I admit this code exists a long time and I do not remember exactly why
it was done this way. I'd suggest you do as proposed and we'll see if
this works out for all Blends as expected. I think this is nothing that
can't be fixed later.
I hope I answered all questions properly.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: