[Erp5-dev] Re: [Erp5-users] ERP5* dependencies and other questions (was: A question regarding ERP5Types)

[Jean-Paul Smets]

Thanks for this work. I think we should move this to erp5-devel.
I will comment on each dependency. We will then need some work to clean this
up.

JPS.

Hello!
Sorry for a delay, I was busy building and playing w/ the packages ;-)

idea? Could it be efficiently used without the rest of ERP5 (I know
that it doesn't depend on it directly)? What are possible
problems and objections? Are there developer-level docs for it?

ERP5Type can be used without ERP5 (the product). It was designed for
that. There might still be useless dependencies. If you can point them,
I can try to remove them.

Using our automatic python dependency tracker, I found the following

What is this tool ? Do you have a URL ?

dependencies (beside standard python and Zope) [at least to provide a
python2.4(psyco)

This can be made an option.

python2.4(Products.BTreeFolder2.BTreeFolder2)
python2.4(Products.BTreeFolder2.CMFBTreeFolder)

This is required because BTreeFolder2 are a must to a few 1,000,000 objects
in a folder. No way to change this.

python2.4(Products.CMFActivity.ActiveObject)

This is a required for active programming. Could become an option if we
implement a fallback class which returns self each time self.activate() is
called. I am not sure it is worth the effort though.

<... a lot of CMFCore modules ...>
python2.4(Products.DCWorkflow)
python2.4(Products.DCWorkflow.DCWorkflow)
python2.4(Products.DCWorkflow.Expression)
python2.4(Products.DCWorkflow.Transitions)

Required if you need workflows. It could be turned as an option too by using
a wrapper class.

python2.4(Products.Localizer)

This dependency can be removed if alternate get_request implementation is
provided in Utils.py

python2.4(Products.CMFCore)
python2.4(Products.CMFCore.utils)
python2.4(Products.ERP5Type)
python2.4(Products.ERP5Type.Base)
python2.4(Products.ERP5Type.Document.Folder)
python2.4(Products.ERP5Type.Error)
python2.4(Products.ERP5Type.Utils)

I think no dependency can be removed. Initial implementation of CMFActivity
was not ERP5Type dependent. Current circular dependency between CMFActivity
and ERP5Type is related to the fact that

- ERP5Type is used as a development framework for CMFActivity
- Base class of ERP5Type benefits from CMFActivity implementation of active
object (activate method)

python2.4(Products.CMFCategory.Category)

CMFCategory could become optional, but then, there would be no way to use
the tree mode in ListBox widget. Defining within ERP5Form an interface for
trees is probably the way to go to break this dependency yet keep all the
features of ListBox. Refactoring is needed and has been done partly
already.

<... various CMFCore modules ...>

CMFCore are required

python2.4(Products.CMFReportTool.RenderPDF.Parser)
python2.4(Products.CMFReportTool.ReportTool)

Could be made optional if you do not care of having a nice PDF report
engine.

python2.4(Products.ERP5.Document.Domain)

Could be made optional.

python2.4(Products.ERP5Type)
python2.4(Products.ERP5Type.Document)
python2.4(Products.ERP5Type.Utils)

No way to remove this dependency.

<... various Formulator submodules ...>
python2.4(psyco)

Could be made optional.

The most interesting part of the game is dependency on
python2.4(Products.ERP5.Document.Domain)
that is we have to install entire ERP5 in order to safely use ERP5Form.

This can be removed (through an option import).

Also CMFReportTool appearently depends on various reportlab modules and

CMFReportTool is a wrapper for reportlab. It is a great PDF generation
system. We could make it optional though.

has dependency python2.4(xml.sax.writer) which is actually a module from
PyXML.

Yes.

I could provide the whole list of dependencies as well as rpm-build
plugin to count them.

Please provide this list (in erp5-devel).

What ERP5Type provides is
- ability to define data schema and semantic constraints in python
without restarting zope (PropertySheet)

Even w/o ALLOW_CLASS_TOOL on the filesystem?

Even w/o ALLOW_CLASS_TOOL (but then without Web interface).

- ability to create new classes on the fly in python (without
restarting zope)
- ability to define menu actions (CMF)
- ability to define complex local role definition (ERP5Type)
- ability to specialise data schema on a per-portal type base (no need
to subclass for that)
- complete separation of data model (PropertySheet), object behaviour
(ERP5Type) and object presentation (ERP5Form)
- relations (if you have CMFCategory installed)

Fine!

Although it is not necessary. It is better to consider using ERP5Type
together with ERP5Catalog and ERP5Form.
- ERP5Catalog provides ability to query Zope objects in SQL, which is
afterall very useful
- ERP5Form provides extended Formulator with a very useful ListBox
widget and some other tools for PDF generation for example
And if you need high performance, CMFActivity is a must because it
distributes the load over nodes in a cluster. It is not required
though.
If you combine ERP5Type, ERP5Catalog and ERP5Form, you can develop new
applications which are completely unrelated to ERP5. One great aspect
of the combination of ERP5Type / ERP5Catalog / ERP5Form is that is has
been tested on ZEO clusters with millions of catalogued objects and
that all performance issues related to size and load are now solved.
If you want to try, my suggestion would be that you first create a mock
up of a mini application based on Kevin tutorial then remove one by
one products. I will be glad to change code in ERP5Type / ERP5Catalog
/ ERP5Form so that useless dependencies are removed.

Ok. Please look at the list above and tell if I can safely skip some of
the requirements (or maybe somehow split a package into smaller ones).
Thank you for your explanations. Now I'm trying to explore the new
possibilities and see if we can easily move to these ERP5* packages.

I think it will be possible to reduce the dependencies a lot.

JPS.

Alexey Morozov.
_______________________________________________
Erp5-users mailing list
Erp5-users at erp5.org
http://erp5.org/mailman/listinfo/erp5-users

[Alexey Morozov]

Hello!

sorry for the delay, too clever thunderbird filters automatically moved
the mail from 'Mailing Lists' folder.

Post by Jean-Paul Smets
Thanks for this work. I think we should move this to erp5-devel.
I will comment on each dependency. We will then need some work to clean this
up.

Actually most of my concerns is not about decreasing list of deps but
rather to clarify things (prob. for documentation and package building
purposes).

Post by Jean-Paul Smets

ERP5Type can be used without ERP5 (the product). It was designed for
that. There might still be useless dependencies. If you can point them,
I can try to remove them.

Using our automatic python dependency tracker, I found the following

What is this tool ? Do you have a URL ?

The tool is built as a part of rpm building process for my distribution
ALTLinux (www.altlinux.org), (which was formerly a fork of Mandrake, but
evolved significantly since the time of fork).

You can grab the source package at

http://distro.ibiblio.org/pub/linux/distributions/altlinux/Sisyphus/files/SRPMS/rpm-build-python-0.21-alt1.src.rpm

or built package at

http://distro.ibiblio.org/pub/linux/distributions/altlinux/Sisyphus/files/noarch/RPMS/rpm-build-python-0.21-alt1.noarch.rpm

The tools discussed are

/usr/lib/rpm/python.req.py

and

/usr/lib/rpm/python.prov.py

which are invoked by rpmbuild deps-counting scripts

Post by Jean-Paul Smets

python2.4(psyco)

This can be made an option.

Ok, but it's not really necessary, it just needs to be declared.

Post by Jean-Paul Smets

python2.4(Products.BTreeFolder2.BTreeFolder2)
python2.4(Products.BTreeFolder2.CMFBTreeFolder)

This is required because BTreeFolder2 are a must to a few 1,000,000 objects
in a folder. No way to change this.

And I don't ask for :-). I just mentioned it as an 'external and
unusual' dependency (python stdlib and Zope were omitted)

Post by Jean-Paul Smets

python2.4(Products.CMFActivity.ActiveObject)

This is a required for active programming. Could become an option if we
implement a fallback class which returns self each time self.activate() is
called. I am not sure it is worth the effort though.

I'm not sure it's worth doing. The module isn't too heavy to depend on.

Post by Jean-Paul Smets

python2.4(Products.DCWorkflow)

Required if you need workflows. It could be turned as an option too by using
a wrapper class.

Sure. But again it's not deadly heavy to rely on DCWorkflow.

Post by Jean-Paul Smets

python2.4(Products.Localizer)

This dependency can be removed if alternate get_request implementation is
provided in Utils.py

thank you for the suggestion.

Post by Jean-Paul Smets

python2.4(Products.CMFCore)
python2.4(Products.ERP5Type)

I think no dependency can be removed. Initial implementation of CMFActivity
was not ERP5Type dependent. Current circular dependency between CMFActivity
and ERP5Type is related to the fact that

Not that problem.

Post by Jean-Paul Smets
- ERP5Type is used as a development framework for CMFActivity
- Base class of ERP5Type benefits from CMFActivity implementation of active
object (activate method)

:-) Have you read the book about Baron Munchausen where he pulled out
himself by the hair from a swamp :-)

Anyway, it's Ok, and no need to break the deps.

Post by Jean-Paul Smets

python2.4(Products.CMFCategory.Category)

CMFCategory could become optional, but then, there would be no way to use
the tree mode in ListBox widget. Defining within ERP5Form an interface for
trees is probably the way to go to break this dependency yet keep all the
features of ListBox. Refactoring is needed and has been done partly
already.

Let's leave it as is, it's a really useful thing.

Post by Jean-Paul Smets
CMFCore are required

Certainly :-)

Post by Jean-Paul Smets

python2.4(Products.CMFReportTool.RenderPDF.Parser)
python2.4(Products.CMFReportTool.ReportTool)

Could be made optional if you do not care of having a nice PDF report
engine.

As far as I checked the code, the whole package can be either split into
two smaller ones (take PDFTemplate.py and corresponding DTMLs into a
separate subpackage) to break the dep or left it as is and rely on
CMFReportTool.

Post by Jean-Paul Smets

python2.4(Products.ERP5.Document.Domain)

Could be made optional.

What should I do for this? Currently it's imported by Selection.py and I
have no idea if it's in active use across the package.

Post by Jean-Paul Smets

python2.4(Products.ERP5Type)

No way to remove this dependency.

No need.

Post by Jean-Paul Smets

The most interesting part of the game is dependency on
python2.4(Products.ERP5.Document.Domain)
that is we have to install entire ERP5 in order to safely use ERP5Form.

This can be removed (through an option import).

What do I loose if I make it optional and how can I do it?

Post by Jean-Paul Smets

Also CMFReportTool appearently depends on various reportlab modules and

CMFReportTool is a wrapper for reportlab. It is a great PDF generation
system. We could make it optional though.

No real need, at least for now.

Post by Jean-Paul Smets

I could provide the whole list of dependencies as well as rpm-build
plugin to count them.

Please provide this list (in erp5-devel).

Ok

Post by Jean-Paul Smets

What ERP5Type provides is
- ability to define data schema and semantic constraints in python
without restarting zope (PropertySheet)

Even w/o ALLOW_CLASS_TOOL on the filesystem?

Even w/o ALLOW_CLASS_TOOL (but then without Web interface).

Fine!

Post by Jean-Paul Smets

Thank you for your explanations. Now I'm trying to explore the new
possibilities and see if we can easily move to these ERP5* packages.

I think it will be possible to reduce the dependencies a lot.

I don't mind against dependencies which are not too heavy and
explainable why they are here.

In the attachment you can find the deps counting scripts together w/
find-requires / find-provides modified to use them. Also to actually get
the dependecies I described above, it might be useful to see how we at
ALT Linux build python and Zope modules. So I attached a typical
python module spec and ERP5Type.spec.

In case somebody wishes to understand about how our python policy and
its supporting macros work, I could give all required explanations.
Sorry, but most docs in rpm-build-python are in Russian at the moment,
but if there's a need I could translate it in English.

Alexey Morozov
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ERP5Type.spec
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20050703/6d255d03/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: python-module-itools.spec
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20050703/6d255d03/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpm_python_macros.tar.gz
Type: application/x-gzip
Size: 10341 bytes
Desc: not available
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20050703/6d255d03/attachment.bin>