RefactorPlan 3.91 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

Here we take notes of the strange stuff, so we can refactor them after
Pardus 2007 release.


==> Locale support
* bindtextdomain and textdomain calls are not necessary, because
gettext.translation() dont use them.

* setlocale call is probably necessary for some stuff, but not for
message translation, it seems gettext.translation() api looks for
environment LC_ALL, LC_MESSAGES anyway.

* pygettext.py shouldn't be needed at all. Plain xgettext works with
python source.


==> Utility functions
* sha1_file and sha1_data functions has some
exception confusion. These two functions should be a lot simpler.

* To estimate required disk size for the packages more accurately we can
calculate package size + (nr of files * inode size of fs).

* Why in a world like this there exists *parse_package* util functions? These must be all methods of package class

* Remove all unneeded util functions, most of them belongs its classes

==> code readability
* Public functions should contain doc strings.

* Python builtins like file, list, etc should be avoided in variable names.
There is even a file.py module!

* a,b,c,d,f,r,_i,A,B,C,G are equally bad.

* some import'ed modules are not used inside the importer modules, cleanup needed.

* Convert all String Concatenation into "%s" % string form which is much faster, readable and correct

==> exceptions
* Current model is bad. Exception names should tell what is the error type. Instead
Suleyman Poyraz's avatar
Suleyman Poyraz committed
43 44 45
we have one Error exception in every module. If I call inary.api.install("lala"),
I should get inary.api.PackageNotFound or inary.install.PackageNotFound or something
like that. For every kind of error, you get inary.api.Error now, and only way to find
46 47 48 49
out exact error is try to parse error string (which is localized).

* class Exception(Exception) is evil.

Suleyman Poyraz's avatar
Suleyman Poyraz committed
50
* There shouldn't be a bare Except: clause in inary modules.
51 52 53 54


==> database
* We should have a DB performance test suite to find important points to make faster,
Suleyman Poyraz's avatar
Suleyman Poyraz committed
55
if we cannot measure, we cannot improve.
56 57 58 59 60

==> class attributes
* In some classes there are some attributes assigned but never
used. (see remove_unused_attributes.patch)

Suleyman Poyraz's avatar
Suleyman Poyraz committed
61
* Inary uses heavy classes and creates thousands of instances of them
62 63 64 65 66 67 68 69 70 71 72 73
  (Package, Metadata, Dependency, ...). These classes should define
  __slots__ to reduce the heap used.


==> actionsAPI
* Get rid of ugly exception model
* Refactor/clean the code
* Add strict checks to models
* Maybe? Get rid of functional logic, switch to OO one
* ActionsAPI still needs an updated API document


Suleyman Poyraz's avatar
Suleyman Poyraz committed
74
==> Inary API
75 76 77 78 79 80 81 82 83 84 85 86 87
* Write a real one


==> Function parameters
* Check function parameters and see if some parameters (especially the
ones named tmpDir/tmp_dir/target_dir) are redundant now. See
http://liste.uludag.org.tr/uludag-commits/2007-February/010070.html

==> Fixes (that need API breakage)
* http://liste.uludag.org.tr/uludag-commits/2007-February/010117.html

==> Logging

Suleyman Poyraz's avatar
Suleyman Poyraz committed
88 89
* Improve logging with all needed update/downgrade/install/remove information so one can easily find the history of packages,
currently Inary wrotes everyting into logs which is not usefull. Also this information can be used for rollback and reporting.
90 91 92

==> function code lengths

Suleyman Poyraz's avatar
Suleyman Poyraz committed
93
* we have some functions that goes pages long... divide all of them to small digestable chunks..
94 95 96 97 98 99 100 101 102 103
  avoid writing functions longer than your editor's screen.

==> assertions

* Lots of assertions used in the code with no following descriptive string information.

==> repo order

* When trying to install a package or looking for a dependency for a package the first found package
  in "repo order" is used. This design decision is not very good. When a new repo that has the latest
Suleyman Poyraz's avatar
Suleyman Poyraz committed
104 105
  version of any package is added and if it is the last repo in order, inary can not upgrade to this
  package.
106 107

  We can remove this order thing and in this situation we can use the latest version of the package.
Suleyman Poyraz's avatar
Suleyman Poyraz committed
108
  This should also lead to some other problems but between these two not very good solutions this
109
  seems to be the better one.