On Wed, 26 Jan 2011, Johnny MariƩthoz wrote:
> I suppose that the first step is to create my own local branch on git,
> then I need to add some files such as templates, css, images.  Do I
> have to put these files in the corresponding directories and edit all
> the Makefile.am files?  Can you suggest an easiest way?

If your customizations are not touching Invenio core, but just adding
things like local CSS and local images and local template skin files and
stuff, then you can also put your changes into a dedicated git
repository of your own, say `invenio-rerodoc', that would be deployed on
top of a given Invenio release branch, adding the files you need.  You
could use your own directory structure there, your own Makefiles or
SCons or setup.py or whatever else is needed.

If your customizations are touching Invenio core, then we should discuss
more this concretely.  Ideally, it should not be necessary to `fork' the
Invenio core too much, but rather to push your needed changes upstream
and wrap them into some configuration variables like
CFG_WEBSUBMIT_EXTERNAL that will do exactly what you need, call your
RERO local stuff, without disturbing other Invenio installations.
Usually, most of your typical locally customized stuff should not touch
Invenio core -- e.g. your formats are named like RERO_HTML_brief.bft,
your output elements like bfe_RERO_title.py, etc; these don't clash with
Invenio, so you can deploy them afterwards in an easily way; you would
need only to `overwrite' Invenio's HB.bfo that lives in `etc' folder.
(Until something like ticket #333 comes true.)  But, if you need to
touch lots of Pyhton files living in `lib', or introduce lots of
CFG_WEBSUBMIT_EXTERNAL variables and friends, then let's discuss
concretely what changes would you need in Invenio core, since there may
be several ways of attacking the issue, some more advantageous that
others.

> If I want to propose a patch. Sending the patch generate by "git
> format-patch" on this list is the correct approach?

Yes, see:
<https://twiki.cern.ch/twiki/bin/view/CDS/GitWorkflow#W7_b_Sending_patches_by_email>

Or just publish your git repo somewhere and I'll fetch from there.

> When I want to test my templates on collections for example, actually I:
> 1) modify the sources
> 2) make install
> 3) chmod -R www-data:www-data /invenio_install_path
> 4) apache graceful
>
> This method is quite painful, can you suggest a better approach?

It is not too painful if you script it away.  E.g. after I edit a file
in my editor, I press C-i and the above steps are performed
automatically.  You can define useful one-liners and aliases such as:

  $ cat $HOME/private/bin/mi
  #!/bin/sh
  make -s && sudo -u www-data make -s install && \
          sudo -u www-data /opt/invenio/bin/inveniocfg --update-all && \
          sudo -u www-data touch /opt/invenio/var/www-wsgi/invenio.wsgi

that helps in dispatching.  If I am working on say WebSearch, then it
takes only one key press to me to deploy my changes; and the deployment
very fast, only 0.2 sec.  If I deploy the whole of Invenio, it takes
more, about 10 seconds -- but one rarely has to do such a global
deployment, since one typically works with one given module at a time.

See also some musings at:
<https://savannah.cern.ch/task/?13992#comment6>

> 5) webcol (to regenerate the cache) or bibreformat for (Details and Brief 
> view)

Note that in the concrete case of testing output formats, you can simply
use the BibFormat Admin interface that offers `live' test preview of the
planned changes on any given record.

> Do you have plan to use a setup.py file or cmake as a remplacement for
> the old automake/autoconf?

Not in the immediate future, though it's definitely a possibility.  The
current autotools-based system works reasonably well and fast, and we
have so many other areas to hack on and improve that switching away from
autotools to something else does not have too much of a priority at the
moment.

Best regards
-- 
Tibor Simko

Reply via email to