Kaydet (Commit) 54e89f07 authored tarafından Faik Uygur's avatar Faik Uygur

Change to project/trunk,tags,branches style


Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

API Plan
Pisi does not have a usable api. All the projects use its internal modules to do their
jobs. This file holds a list of these usages by project as a guide for a new competent
pisi api.
Below are pisi's internal calls that they may help to figure out common api calls.
* packagedb.remove_repo
* sourcedb.remove_repo
* packagedb.which_repo
* repodb.get_repo
* packagedb.get_package
* installdb.is_installed
* packagedb.get_rev_deps
* installdb.get_version
* packagedb.has_package
* packagedb.add_package
* componentdb.add_package
* filesdb.has_file
* filesdb.get_file
* installdb.get_info
* installdb.files
* installdb.pkg_dir
* installdb.install
* filesdb.add_files
* componentdb.add_spec
* sourcedb.add_spec
* componentdb.get_union_comp
* componentdb.remove_spec
* installdb.get_version
* componentdb.remove_repo
* componentdb.remove_package
* componentdb.update_component
* componentdb.add_package
* installdb.remove
* filesdb.remove_files
* sourcedb.pkgtosrc
* sourcedb.get_spec
* sourcedb.get_source
* sourcedb.get_spec_repo
* repodb.get_repo
* componentdb.has_component
* componentdb.get_component
* installdb.is_installed
* packagedb.list_packages
* installdb.list_installed
* componentdb.get_union_packages
* componentdb.list_components
* repodb.list
* sourcedb.list
* installdb.list_pending
* filesdb.match_files
Package Manager
Below are the pisi modules used internally by package-manager. Package-manager should use pisi
* repodb.get_repo
* packagedb.get_package
pm still uses the old packagedb with pisi.itemsbyrepo.installed or pisi.itemsbyrepo.repos params
* componentdb.list_components
* repodb.list
* componentdb.get_union_comp
* componentdb.get_union_packages
Below are the pisi modules used internally by Yali. Yali should use pisi api.
* api.add_repo
* api.update_repo
* api.remove_repo
* api.install
* packagedb.list_packages
* installdb.list_pending
* api.configure_pending
* packagedb.get_package
Below are the pisi modules used internally by Buildfarm.
* api.create_delta_package
Below are the pisi modules used internally by PackageKit.
* installdb.has_package
* installdb.get_package
* packagedb.has_package
* packagedb.get_package
* installdb.get_rev_deps
* packagedb.get_rev_deps
* installdb.get_package.runtimeDependencies
* packagedb.get_package.runtimeDependencies
* api.install
* api.upgrade
* api.remove
* api.list_upgradable
* api.update_repo
* api.list_repos
* repodb.get_repo.indexuri.get_uri
* version.Version
* util.any
Like every serious project, there are guidelines.
"Coding Standards" for serious.
0. Before reading any further please observe
PEP 8: Style Guide for Python Code
In particular this means no lameCaps
1. When using dirnames, don't expect the dir to end
with a trailing slash, and please use the dirnames
in pisiconfig. Use util.join_path instead of os.path.join
2. Python indentation is usually 4 spaces.
3. Follow python philosophy of 'batteries included'
4. Use exceptions, don't return error codes
5. Don't make the PISI code have runtime dependencies on
a particular distribution (as much as possible).
6. Don't assume narrow use cases. Allow for a mediocre
amount of generalization in your code, for pieces that
will be required later.
7. If you are changing something, check if that change
breaks anything and fix breakage. For instance a
name. Running the tests is not always enough!
8. A good design ensures separation of concerns. Every module
has a specific documented responsibility. Don't make the
horse clean your windows.
9. To ensure readability avoid nesting python constructs
more than 3 levels deep. Python is a good language (unlike C),
so you can define inner functions in a convenient way, use
such decomposition techniques to break down your code into
manageable chunks. The worst code you can write is one huge
procedure that goes on for 1000 (or more) lines.
10. Use a particular abstraction like a class or function only
if it makes sense. Don't just define things because they can
be defined. Define only things that will/may be used.
11. If you are doing an expensive task like searching through
10000 text chunks, please use an efficient data structure
and algorithm. We are not MS engineers who know no data
structure beyond doubly linked lists and no algorithm beyond
12. Resist the temptation to develop kludges and workarounds in
response to pressure. Take your time to solve the problems by
the book. The payoff comes later.
13. Same thing goes for premature optimizations. Knuth and Dijkstra
are watching over your shoulder. :)
Branches and SVN
There are two branches of pisi, one is called pisi-devel and
new features that are large enough to cause instability go
into that branch. The trunk version is supposed to be stable at
all times. This means that you *must* run unit tests and other
test scripts after committing any change that cannot be tested
in isolation. Run the unit tests periodically to catch unseen
bugs. A release from the stable branch *must not* break any tests
whatsoever, so extensive use of the test suite must precede any
Unit testing
Unit tests are located in unittests directory. Running the tests is
trivial. But you must synchronize your code and data with the test
code, which can be a tedious work if you lose discipline.
Sample data files are located in the same directory with test modules.
For running the entire test suite, use the following command:
$ ./tests/run.py
The following command will run tests in specfiletests and archivetests
in unittests dir:
$ ./tests/run.py specfile archive
Do not depend on the output of unittests. Instead of producing an
output message/data in your tests, check the data internally. By
definition, unittest should just report succeeding and failing cases.
If you didn't, take a look at the links below for having an idea of
unit testing.
Other tests
There are a couple of nice test scripts for testing the basic
capabilities of the command line interface such as building and
upgrading. Unlike unit tests, you have to take a look at the output
to understand that the scripts are doing well :)
Misc. Suggestions
1. Demeter's Law
In OO programming, try to invoke Demeter's law.
One of the "rules" there is not directly accessing any
objects that are further than, 2/3 refs, away. So the
following code is OK.
but the following isn't as robust
As you can tell, this introduces too many implementation
dependencies. The rule of thumb is that, in these cases
this statement must have been elsewhere.... It may be a
good idea to not count the object scope in this case,
so in Python self.a means only one level of reference,
not two.
One quibble with this: it may be preferable not to insist
on this where it would be inefficient. So if everything
is neatly packed into one object contained in another
object, why replicate everything in the upper level? If
the semantics prevents dependency changes, then chains
of 3 or even 4 could be acceptable.
OTOH, in Python and C++, it's not always good to implement
accessor/modifier pairs for every property of an object.
It would be much simpler if you are not doing any special
processing on the property (e.g. if what the type system
does is sufficient).
The main rule of thumb in Demeter's Law is avoiding
putting more than, say, 10 methods in a class. That works
really well in practice, forcing refactoring every now
and then.
2. We all know, you're using LISP but didn't want to tell
us. Don't be scared, as a success story and for your encouragment
there are tens of people somewhere with LISP releated jobs.
3. If you are studying Data structures and Algorithms, and if
your first assignment is to implement a basic FIFO queue,
don't implement it. Just show your teacher the syntax of LISP,
tell him how beautiful it is, and show how an autistic person
can count lots of parenthesis with a "one second" look, you'll
probably get A+.
4. If you are interested in "Playstation 2 Linux Games Programming"
or "How to extend C programs with Guile", please don't exercise
your valuable skills in this project.
This diff is collapsed.
You can install PiSi on your system with a single command.
# ./setup.py install
If you are on a Pardus system, you should delete /usr/lib/pardus/pisi
when you are installing the SVN version
PiSi requires piksemel XML processing library, Pardus configuration
manager COMAR and COMAR API in order to run.
If you are upgrading from an old PiSi release you may have to
run the following command as root:
# pisi rebuild-db
recursive-include po *
recursive-include tests *.py
recursive-include tools *
recursive-include doc *
include . *.dtd
PISI - Packages Installed Succesfully as Intended
PISI is a new package manager for the PARDUS
distribution. In Turkish PISI means "kitty", and
like a kitty, it is featureful and small.
Some of its distinctive features:
- Implemented in python
- Efficient and small
- Package sources are written in XML and python
- Uses LZMA for a better compression ratio
- Fast database access implemented with berkeley DB
- Integrates low-level and high-level package operations (dependency resolution)
- Framework approach to build applications and tools upon
- Comprehensive CLI and a user-friendly qt GUI (distributed separately)
- Extremely simple package construction
For upgrading from pisi 1.0 and before
You have to move the packages in /var/lib/pisi under /var/lib/pisi/package and remove /var/db/pisi/ directory.
db version has changed, so a rebuild-db will be unfortunately necessary.