0install

Why

0install is used as cross-platform dependency resolver for not having to package the projects' releases for multiple package managers.

This allows:

• modular, flexible development (single source principle).
• using the same toolchain for developing all kinds of projects (not only code)
• on all operating systems.
• version control.
• depending on modules in any revision range (unlike Git submodules)
• distributed using any version control or package management system
• following API dependent release versioning conventions (incompatible_api_change_increment.minor_version.fix-release_candidate_or_suffix) for being able to specify a wider compatible version range
• automatic backup of projects (because of distributed development).
• easy testing of modules locally without breaking the system due to multiple versions of a package.
• developer interaction (world wide team work) without being forced to release just to allow other developers to fetch the new changes (because Git is the base system)
• users turning into developers with ease (because 0install is used for releases and can fetch the sources, i.e. the Git repository contents).
• easily fetching, inspecting the sources of a project in a certain version. (e.g. to debug or further develop / fork a local version, this can be rebased later on)
• preventing dependency mess.
• linear project history (not mandatory but possible) and all other version control system powers.
• having the 0install XML file under version control where it belongs: in the same repository where the project sources reside.
• aliasing filenames a project depends upon to a functional general name to be able to exchange a file (e.g. a used image or schematic) later without updating all used references e.g. in FreeCAD or blender files (which may be binary where search replace does not work easily).
• referencing files of dependencies using relative links (as if the dependencies were located as a folder in the current working directory
• to increase development consistency.

How to package

A module package version is released directly in the Git repository. See 0install, git interaction outlined under #Why.

It is packaged using the repository contents. => No magic extra ingredients to be figured out, then merged.

The resulting package can be hosted in the version control repository but it might be desirable to have it separate for big release data amounts. The package URI is provided in the 0install XML file.

How to install, depend on a module

Install a module / package:

   0install add <repository.uri>/<module>.xml

Depend on a module by using the 0install XML file URI of the corresponding module repository.

Module naming convention

Generally this is a subjective matter and it will never be used consistently in the world. Thus the exact naming is not too important as long as it is used consistently within a project which 0install supports using symbolic links / aliases.

However within projects of engineering clubs, this can be kept as consistent as possible by following basic rules:

Use nouns

• A module has a purpose which a conscious being is giving to the thing. (We are intellectual beings, we do develop this construct for a reason!)
• It can have more than one functions, uses defined by its capabilities.
• And can be made happen using one or multiple technologies.

When one considers that a module

• can be based on other modules (inheritance)
• and override/modify existing runtime files by providing the same file as a dependency. This will not take effect for compilation or preprocessing.
• can use any number of other modules (dependencies).
• may be used by 1..n other modules (reverse dependencies)

where n is a natural number.

• => Then it becomes apparent that a module name should use nouns, especially because we are interested in constructs (and constructs are things) that we desire to put together virtually or physically because we have a purpose for every one of it.*

Why not to use a grammar like Lojban, English, Chinese?

Lojban

• is not widely known.
• Must be learned by developers first.
• Is like programming and useful for conveying uniquely defined messages (the purpose of language?!).

Concerning Chinese and English grammar

• most projects/modules would use transitive verbs that take objects while the subject is not important or generic (e.g. <subject>_control_motor), thus omitted (control_motor) and
• subject_verb_object creates discrepancies when stacking modules recursively, because only things can be stacked and one can not e.g. stack control_spider_leg onto move_spider_leg_base without confusion.
• verbs imply one function / use while a construct may have more functions, consider a motor controller that may limit current and control speed at the same time. Restricting a module to one function may be unwise.

Please comment/ discuss this page if you think there is something important to be added or if there is a consistent naming scheme using language grammar that is generally applicable to project / module naming.

General to specific

This implies more reasons for using nouns instead of verbs, because

• subject_verb_object contradicts from general to specific naming convention, e.g. electronics_control_motor_speed and mechanics_control_motor_speed versus motor_controller, motor_brake_mechanic, motor_brake_electromagnetically which eases depending on both modules for redundancy, too.

Goal: Provide at least one module for every purpose.

If we want to construct a mobile machine then we want it to transport something or someone. This mobile machine may be driven by an electromagnetic motor and because there is a desire to control vehicle speed, and many vehicle kinds may be useful for fulfilling some purpose, we hence define a motor controller module sooner or later. Its purpose is to control a motor. There may be variants for alternating and direct current.

Naming after purpose

When we develop a universal machine to help with the harvest, water transport and tree trunk transport why not call it as such?

e.g. harvest_transporter harvest_transport_vehicle tree_trunk_transporter transporter_tree_trunks transporter transporter_open transporter_closed transporter_container (module for transporting liquids) transporter_mesh transporter_mesh_container (for hay?)

Many possibilities.

At least one might agree that calling it:

• transporter_for_liquid

might not be helpful because one thinks that this is a new transporter for liquid and not a submodule that adds liquid transport capabilities to the transporter.

Examples

The level of modularity is subjective because it depends on something atomar really existing. It may be sensible to start general and on demand subdivide further to allow reuse by other modules to follow the single source principle and Unix package principle (1 task, 1 program) without having to pull in a huge set of files that are not needed. Consider depending on spider_leg but it being contained within hexapod or octopod.

• spider_leg
• pod
• hexapod
• tank_track (Why
• tank (Why build it? Because it protects us while fighting!)

Optionally (at e.g. a later point of time) this can be further modularized for arbitrary stacking/exchange of modules:

• spider_leg_segment
• spider_leg_segment_joint
• spider_leg_segment_joint_transmission or just spider_leg_transmission

More examples

• motor_controller
• motor_controller_dc
• motor_controller_ac
• motor_controller_ac_three_phase
• generator_load_controller
• generator_load_controller_electronic
• generator_load_controller_mechanic

are other examples for functionally separate, self contained repositories where the generator_load_controller may contain common files like documentation or evaluation of different control techniques.

current_sensing

motor_step_controller motor_step_controller__current_sensing is a modification/addition to allow micro stepping without redefining common circuits like power or the H bridge. It would depend on motor_step_controller obviously as well as on current sensing for then fine tuning the design for micro stepping.

__ as separator convention

The double __ is just one possible convention.

This is analog to Python modules which uses a hyphen e.g. python-numpy is serving a purpose and depends/operates on python itself. Of course it is not wise to put all depedencies into the name as these may change and are likely many. It is just that numpy (numeric python) is a part of the python scope because it is written in python, thus fine tuned for python versus using a similar library written in e.g. C.

• => This special fine tuning for one module is what can be used to decide when to prepend a base module's name to the module name.*

The difference is that worlddevelopment.0install convention uses _ instead of - because underscore is in a more basic character set than -+,;:0123456789 are and allows easier machine interfacing later on because a machine has to do extra work to know when a hyphen - is a logical separator and when it is part of a word like "add-on", so if you have a module bending_machine-add-on and a submodule bending_machine-add-on-submodule then it becomes messy which is why the convention uses bending_machine__add-on-module.