RefactorPlan 3.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110
  1. Here we take notes of the strange stuff, so we can refactor them after
  2. Pardus 2007 release.
  3. ==> Locale support
  4. * bindtextdomain and textdomain calls are not necessary, because
  5. gettext.translation() dont use them.
  6. * setlocale call is probably necessary for some stuff, but not for
  7. message translation, it seems gettext.translation() api looks for
  8. environment LC_ALL, LC_MESSAGES anyway.
  9. * pygettext.py shouldn't be needed at all. Plain xgettext works with
  10. python source.
  11. ==> Utility functions
  12. * sha1_file and sha1_data functions has some
  13. exception confusion. These two functions should be a lot simpler.
  14. * To estimate required disk size for the packages more accurately we can
  15. calculate package size + (nr of files * inode size of fs).
  16. * Why in a world like this there exists *parse_package* util functions? These must be all methods of package class
  17. * Remove all unneeded util functions, most of them belongs its classes
  18. ==> code readability
  19. * Public functions should contain doc strings.
  20. * Python builtins like file, list, etc should be avoided in variable names.
  21. There is even a file.py module!
  22. * a,b,c,d,f,r,_i,A,B,C,G are equally bad.
  23. * some import'ed modules are not used inside the importer modules, cleanup needed.
  24. * Convert all String Concatenation into "%s" % string form which is much faster, readable and correct
  25. ==> exceptions
  26. * Current model is bad. Exception names should tell what is the error type. Instead
  27. we have one Error exception in every module. If I call inary.api.install("lala"),
  28. I should get inary.api.PackageNotFound or inary.install.PackageNotFound or something
  29. like that. For every kind of error, you get inary.api.Error now, and only way to find
  30. out exact error is try to parse error string (which is localized).
  31. * class Exception(Exception) is evil.
  32. * There shouldn't be a bare Except: clause in inary modules.
  33. ==> database
  34. * We should have a DB performance test suite to find important points to make faster,
  35. if we cannot measure, we cannot improve.
  36. ==> class attributes
  37. * In some classes there are some attributes assigned but never
  38. used. (see remove_unused_attributes.patch)
  39. * Inary uses heavy classes and creates thousands of instances of them
  40. (Package, Metadata, Dependency, ...). These classes should define
  41. __slots__ to reduce the heap used.
  42. ==> actionsAPI
  43. * Get rid of ugly exception model
  44. * Refactor/clean the code
  45. * Add strict checks to models
  46. * Maybe? Get rid of functional logic, switch to OO one
  47. * ActionsAPI still needs an updated API document
  48. ==> Inary API
  49. * Write a real one
  50. ==> Function parameters
  51. * Check function parameters and see if some parameters (especially the
  52. ones named tmpDir/tmp_dir/target_dir) are redundant now. See
  53. http://liste.uludag.org.tr/uludag-commits/2007-February/010070.html
  54. ==> Fixes (that need API breakage)
  55. * http://liste.uludag.org.tr/uludag-commits/2007-February/010117.html
  56. ==> Logging
  57. * Improve logging with all needed update/downgrade/install/remove information so one can easily find the history of packages,
  58. currently Inary wrotes everyting into logs which is not usefull. Also this information can be used for rollback and reporting.
  59. ==> function code lengths
  60. * we have some functions that goes pages long... divide all of them to small digestable chunks..
  61. avoid writing functions longer than your editor's screen.
  62. ==> assertions
  63. * Lots of assertions used in the code with no following descriptive string information.
  64. ==> repo order
  65. * When trying to install a package or looking for a dependency for a package the first found package
  66. in "repo order" is used. This design decision is not very good. When a new repo that has the latest
  67. version of any package is added and if it is the last repo in order, inary can not upgrade to this
  68. package.
  69. We can remove this order thing and in this situation we can use the latest version of the package.
  70. This should also lead to some other problems but between these two not very good solutions this
  71. seems to be the better one.