Crushinator is a project mainly written in Python, it's free.
.. note:: This document is still in heavy flux, please consult the source, the issue tracker, mailing list chatter, and other resources before relying on the contents of this document.
This notice will be removed when the package layout has stabilized.
This is the root of the Crushinator
project, a special one-stop repository
that combines the development (and installation) of several independant
(but related) python packages:
crushinator.framework
, the core classes defining the API that all Crushinator
-based
projects implment.crushinator.toolkit
, a set of common implementations of various components covering
many different use-cases. Crushinator
, a set of reference implementations showing the different types
of front-end user interfaces. Considered production-quality code, and safe to use in lieu
of (or in tandem with) another preferred front-end user interface. Installs a central
crushinator script if installed directly.crushinator.integrationtests
, a special egg containing integration tests. Not released. .. note:: There will most likely be a few more support packages, covering more broad implementations
of some of the components of the Crushinator
package. These will be stored in separate
python eggs. The idea is that if you want to use a particular implementation of a component,
but don't need the full implementation (or you want to wrap it.)
A good example might be a generation system that builds Djang-based apps. There may be a big
savings in time if you can extract just the ``Seletons`` and extend the ``User Interfaces``,
instead of depending on the whole ``Crushinator`` package.
Consider this repository a suite of packages. Each should be autonomous (save for a dependancy on
crushinator.framework
), and can be developed and tested separately. They're brought together here,
not just to keep the author's administration headache to a minimum, keeping issues, documentation, and other
artifacts in a central place, but also to allow a logical location for broader integration tests.
This README lives within a zc.buildout structure, used for testing and to provide a consistent, almost instant development environment.
The src
directory contains the source code for crushinator.framework
, and the other
packages described above. Each subdirectory within is a complete python egg file structure.
The docs
folder contains design, implementation, and userland documentation. It (like
this file) is written in reStructuredText, and is written for documentation to be generated
with Sphinx
.
Each egg structure in src
mirrors this one in terms of documentation. There is a README.rst
file explaining what the package does and quick start/installation instructions.
Each egg also contains a docs
directory, containing more detailed documentation, API references, userland docs, etc.
Unit and functional tests are located in the tests
directory within the module structure (e.g. crushinator.framework.tests
).
See Developing Crushinator
_ for further details and instructions on using the
included buildout.cfg
(the recommended method), or a virtualenv
environment.
See Testing Crushinator
_ for more information about writing and running tests.
See Documenting Crushinator
_ for documentation guidelines and instructions on generating the user manual.
The Crushinator
packages are versioned incrementally, using a 3 part numeric notation (e.g., 1.2.3). There is no
anticpated limit for any of the component numbers (so 100202202.212121243123412.242345345423563456 is theoretically possible, but not likely).
All numbers start at 0.
Alphas, Betas, Release Candidates, and other specialized releases will be indicated with a dash (-) and a few characters to indicate the purpose. Some examples:
With the exception of a very few situations, special releases will always be on 'full' releases, e.g., a version with no bugs (e.g. X.X.0)
A quick counting example:
.. note:: This may not reflect the actual release cycle; At this point there's no indication that a release candidate step or alphas/betas will be strictly necessary.
TODO
Using a Virtualenv
------------------
TODO
TODO
Generating The User Manual
--------------------------
TODO
TODO