The most obvious aspect of PiSi is its simplicity. From its svn-like console interface – pisi-cli, to its package building mechanism, it is very easy to grasp the inner workings and use effectively. It is so simple that when the first PiSi source code was revealed with some example source packages, it only took twenty-minutes for someone to contribute a new package to Pardus. And there was no documentation about the build system whatsoever. Xml based source packaging system is so intuitive and easy to grasp that it almost needs no documentation.
When you look at traditional package managers, you can see that the variety of tools for managing and package building, create an unnecessarily complicated system.
The first complication comes from the different tools that, combined, make the desired package management possible. The so called native package managers (DPKG, RPM, etc.) do the house-keeping jobs and above them there exists many other ‘wrapper’ tools (apt, dselect, urpmi, yum, aptrpm, etc.) for mainly handling the dependency resolution, package selection and installation issues. But the main complication and difficulty comes from the various build helper tools, ad-hoc source specification formats and build scripts. The learning curve is steep for new developers.
PiSi architecture is quite different from traditional designs. Every functionality related to package management like installing, building, dependency solving, fetching, validating and repository management is in the core of PiSi. On the other hand, package configuration is clearly separated from the package management system and is delegated to COMAR. The configuration system is not limited to pre-remove or post-install scripts; it is a much more advanced system, configuring all the installed packages in a unique way using the same COMAR API. A package may provide a configuration service script to be used as a configuration interface for itself. Configuration of packages can be done remotely or locally.
Traditionally, build scripts for packages are shell scripts. The shell is ideal for simple tasks, like batch run of a series of commands, with maybe some conditionals but nothing more. Shell scripting is awkward. It needs many other additional helper tools with their own syntax and usage. Moreover, debugging and maintenance costs are high. When it comes to a complex task like building a package, you need conditional operations, string manipulations, iteration over series of data, and many other operations from higher scripting languages, along with additional advantages. And for those reasons, Python was chosen for all of the distribution's core components due to its simplicity, flexibility and easing of maintenance.