Difference between revisions of "PyOGP Client Library File System"

From Second Life Wiki
Jump to navigation Jump to search
(expanded description of the buildout structure and added some links to documentation)
Line 19: Line 19:
   from pyogp.lib.base import *
   from pyogp.lib.base import *


Other packages can claim part of the same namespace like 'pyogp.lib.somethingelse'. This is a feature of Python Eggs.
Other packages can claim part of the same namespace like 'pyogp.lib.somethingelse' without being in the same directory as it would be the case usually in Python. This is a feature of Python Eggs and explained here.


Because of this the packages are named like their namespace. The contents of these packages is also following this path structure and 'pyogp.lib.base' for instance looks like this:
Because of this the packages are named like their namespace. The contents of these packages is also following this path structure and 'pyogp.lib.base' for instance looks like this:
Line 27: Line 27:
  pyogp/lib/base
  pyogp/lib/base


The actual code is to be found in 'pyogp/lib/base'.  
The actual code is to be found in 'pyogp/lib/base'. All the other directories should not be touched unless you know what you are doing.


The top directory of each egg (pyogp.lib.base in our example) also contains a file called 'setup.py' which is a configuration file for that egg. This will be explained later.
Python eggs in src/ are usually subversion externals, meaning that they are just referenced. You can see the externals used in src/EXTERNALS.txt. This gives us the flexibility to use the source checkout of those eggs in different buildouts with different configurations and additionally also to use packages from other repositories if needed.
 
The top directory of each egg (pyogp.lib.base in our example) also contains a file called 'setup.py' which is a configuration file for that egg. You can read about these files in the [http://docs.python.org/dist/dist.html Distutils] and [http://peak.telecommunity.com/DevCenter/setuptools setuptool] documentation.


For more information on how the actual source code is structure inside a package look at [[pyogp/Package Best Practices|Package Best Practices]].
For more information on how the actual source code is structure inside a package look at [[pyogp/Package Best Practices|Package Best Practices]].

Revision as of 12:27, 30 June 2008

the buildout filesystem structure

Here is a rundown of the Filesystem structure of the pyogp development sandbox:

  • bin - contains all executable which might be provided by the library eggs. Also contains the buildout script which is needed later for updating packages.
  • bootstrap.py - only used for the buildout bootstrapping process.
  • buildout.cfg - the buildout configuration file. This is explained in more detail in the Buildout Introduction
  • develop-eggs - contains links to eggs which are in development right now (usually links to src/)
  • eggs - contains the eggs (python packages) which are installed locally in this buildout
  • parts - used by buildout for downloading and installing packages
  • src - contains the actual source code of the library, test harness and so on.


the src/ directory

The src/ directory contains all the packages we are developing right now. These packages are also called Python Eggs. Each package usually has a namespace like 'pyogp.lib.base'. This can later be used like this:

 from pyogp.lib.base import *

Other packages can claim part of the same namespace like 'pyogp.lib.somethingelse' without being in the same directory as it would be the case usually in Python. This is a feature of Python Eggs and explained here.

Because of this the packages are named like their namespace. The contents of these packages is also following this path structure and 'pyogp.lib.base' for instance looks like this:

pyogp/
pyogp/lib
pyogp/lib/base

The actual code is to be found in 'pyogp/lib/base'. All the other directories should not be touched unless you know what you are doing.

Python eggs in src/ are usually subversion externals, meaning that they are just referenced. You can see the externals used in src/EXTERNALS.txt. This gives us the flexibility to use the source checkout of those eggs in different buildouts with different configurations and additionally also to use packages from other repositories if needed.

The top directory of each egg (pyogp.lib.base in our example) also contains a file called 'setup.py' which is a configuration file for that egg. You can read about these files in the Distutils and setuptool documentation.

For more information on how the actual source code is structure inside a package look at Package Best Practices.