Author: Erkan Ozgur Yilmaz



Stalker is an Open Source Production Asset Management (ProdAM) Library designed 
specifically for Animation and VFX Studios but can be used for any kind of
projects. Stalker is licensed under LGPL v2.1.

 * Designed for animation and VFX Studios.
 * Platform independent.
 * Default installation handles nearly all the asset and project management 
   needs of an animation and vfx studio.
 * Customizable with configuration scripts.
 * Customizable object model (Stalker Object Model - SOM).
 * Uses TaskJuggler as the project planing and tracking backend.
 * Can be used with any kind of databases supported by SQLAlchemy.
 * Can be connected to all the major 3d animation packages like Maya, Houdini,
   Nuke, Softimage, Vue, Blender etc. and any application that has a Python

Stalker is build over these other OpenSource projects:
 * Python
 * SQLAlchemy and Alembic
 * Jinja2
 * TaskJuggler

Stalker as a library has no graphical UI, it is a python library that gives you
the ability to build your pipeline on top of it. There are other python
packages like the Open Source Pyramid Web Application `Stalker Pyramid`_ and
the Open Source pipeline library `Anima`_ which has PyQt/PySide UIs for
applications like Maya, Nuke, Houdini, Eyeon Fusion, Photoshop etc.

.. _`Stalker Pyramid`:
.. _`Anima`:


The latest development version is available in `GitHub`_ page of Stalker or can
be directly cloned with the following command if you already have git

  git clone

.. _GitHub:

Stalker Changes

* **Update:** ``TaskJugglerScheduler`` is now 466x faster when dumping all the
  data to TJP file. So with this new update it is taking only 1.5 seconds to
  dump ~20k tasks to a valid TJP file where it was around ~10 minutes in
  previous implementation. The speed enhancements is available only to
  PostgreSQL dialect for now.

* **Fix:** Fixed TimeLog output in one line per task in ``Task.to_tjp()``.

* **New:** Added ``TaskJugglerScheduler`` now accepts a new argument called
  ``compute_resources`` which when set to True will also consider
  `Task.alternative_resources` attribute and will fill
  ``Task.computed_resources`` attribute for each Task. With
  ``TaskJugglerScheduler`` when the total number of Task is around 15k it will
  take around 7 minutes to generate this data, so by default it is set to


* **New:** Added ``efficiency`` attribute to ``User`` class. See
  :class:`.User` documentation for more info.

* **Fix:** Fixed an **autoflush** problem in ``Studio.schedule()`` method.

* **New:** Added ``Repository.make_relative()`` method, which makes the given
  path to relative to the repository root. It considers that the path is
  already in the repository. So for now, be careful about not to pass a path
  outside of the repository.

* **Update:** ``TaskJugglerScheduler.schedule()`` method now uses the
  ``Studio.start`` and ``Studio.end`` values for the scheduling range instead
  of the hardcoded dates.

* **Update:** ``Task.create_time_log()`` method now returns the created
  ``TimeLog`` instance.

* **Fix:** Fixed an ``autoflush`` issue in
  ``Task.update_status_with_children_statuses()`` method.

* **Update:** ``Studio.is_scheduling`` and ``Studio.is_scheduling_by``
  attributes will not be updated or checked at the beginning of the
  ``Studio.schedule()`` method. It is the duty of the user to check those
  attributes before calling ``Studio.schedule()``. This is done in this way
  because without being able to do a db commit inside ``Studio.schedule()``
  method (which is the case with transaction managers which may be used in web
  applications like **Stalker Pyramid**) it is not possible to persist and thus
  use those variable