Project:Portage/Repoman-TODO

From Gentoo Wiki
Jump to:navigation Jump to:search
The information in this article is representative of former times and has been archived. It can be used for reference, but is most likely not appropriate for current usage. Generally, archived articles should not be edited.

Here we will keep track of changes to be done in the portage/repoman refactor:

TODO

Stage 1:

   * Split up the code into a reasonable file structure, 
     creating individual tests or groups of tests using a common class style.
   * Correct the Copyright headers.
   * Fix the PEP8, pyflakes and pylint warnings and/or errors.
   * Create namedtuple QA classes for tracking problems
   * Refactor _xml.XmlLint for saving error messages to add to a new QA tracking class

Stage 2

VCS Code Classes

Please use This commit as an example of an intermediate vcs handling system. commit ca10e65ff2b26f8aa716210b3155c9e5dc12b643

Note it's use of getattr() in the scan() which automatically calls the correct vcs scan_*().

Similarly any test code can be broken out to it's own class, then the vcs specific code can be broken up within that class. During stage 2 of the rewrite, the vcs specific code can be moved to a proper vcs plugin system.

Slicing and Dicing the code...

There are several class instances created before the main xpkg test loop. They are for tracking the errors found, etc..

CODE
####################

dev_keywords = dev_keywords(profiles)

qatracker = QATracker()</pre>

Initialize the new test classes before the main loop with any static data. This is currently around lines 332+

CODE Excerpt from repoman/main.py
######################
# initialize our checks classes here before the big xpkg loop
manifester = Manifests(options, qatracker, repoman_settings)
is_ebuild = IsEbuild(repoman_settings, repo_settings, portdb, qatracker)
filescheck = FileChecks(
	qatracker, repoman_settings, repo_settings, portdb, vcs_settings)
status_check = VCSStatus(vcs_settings, qatracker)
fetchcheck = FetchChecks(
	qatracker, repoman_settings, repo_settings, portdb, vcs_settings)
pkgmeta = PkgMetadata(options, qatracker, repoman_settings)
thirdparty = ThirdPartyMirrors(repoman_settings, qatracker)
use_flag_checks = USEFlagChecks(qatracker, uselist)

keywordcheck = KeywordChecks(qatracker)
liveeclasscheck = LiveEclassChecks(qatracker)
rubyeclasscheck = RubyEclassChecks(qatracker)
eapicheck = EAPIChecks(qatracker, repo_settings)
descriptioncheck = DescriptionChecks(qatracker)
licensecheck = LicenseChecks(qatracker, liclist, liclist_deprecated)
restrictcheck = RestrictChecks(qatracker)
######################

for xpkg in effective_scanlist:
	# ebuilds and digests added to cvs respectively.
	logging.info("checking package %s" % xpkg)

The tests should get any dynamic data passed in the the test classes test function at run time.

CODE
#######################
	filescheck.check(
		checkdir, checkdirlist, checkdir_relative, changed.changed, changed.new)
#######################
	status_check.check(check_ebuild_notadded, checkdir, checkdir_relative, xpkg)
	eadded.extend(status_check.eadded)

#################
	fetchcheck.check(
		xpkg, checkdir, checkdir_relative, changed.changed, changed.new)
#################
Note
The use of the ################ lines is to help break up the code and be place/separation markers markers for where code chunks were removed and replaced with the test call... They will be cleaned out at a later time. I've found them to help troubleshoot the code changes, track down bugs that occurred due to other code being removed that generated variables/data that was needed for the current test.

Stage 3:

Customization of Checks

  • allow checks to be enabled and disabled with USE-like -* and -foo settings ===> Done
  • allow checks to made added or removed from the warnings/fatal groups using USE-like -* and -foo settings ===> Done
  • PR submitted for review ===> Done
  • Make additional changes from review comments ===> Done
  • waiting for PR approval
  • update/create docs on the module systems scan and linechecks modules.
  • define groups of checks, similarly to how license groups are defined, and use them to select or reject groups of checks