Cubicweb

Cubes

• cubicweb-bootstrap 0.6.6, 1.0.0, 1.0.1, 1.0.2
• cubicweb-ckanpublish 0.1.0, 0.2.0
• cubicweb-comment 1.11.0
• cubicweb-company 0.6.1
• cubicweb-forge 1.11.0
• cubicweb-forgotpwd 0.6.2
• cubicweb-iprogress 0.2.0
• cubicweb-mandrill 0.4.0
• cubicweb-nosylist 0.6.0
• cubicweb-preview 1.1.1
• cubicweb-registration 0.6.1
• cubicweb-slickgrid 1.0.0
• cubicweb-squareui 0.3.8, 1.0.0
• cubicweb-testcard 0.5.0
• cubicweb-tracker 1.16.2, 1.16.3
• cubicweb-trackervcs 1.3.0
• cubicweb-trustedauth 0.3.1
• cubicweb-varnish 0.3.0
• cubicweb-vcreview 2.1.0, 2.1.1
• cubicweb-vcsfile 2.0.1, 2.0.2, 2.0.3
• cubicweb-worker 3.0.5
• cubicweb-wsme 0.1.6
• narval 4.1.2
• pyramid-cubicweb 0.2.0, 0.2.1

Agenda

Next roadmap meeting will be held at the beginning of may 2015 at Logilab. Interested parties are invited to get in touch.

New integrators

Rémi Cardona (rcardona) and Denis Laxaldle (dlaxalde) have now the publish access level on Cubicweb repositories.

Security context

Christophe exposed his proposal for a "security context" in Cubicweb, as exposed in https://lists.cubicweb.org/pipermail/cubicweb/2015-February/002278.html and https://lists.cubicweb.org/pipermail/cubicweb/2015-February/002297.html with a proposition of implementation (see https://www.cubicweb.org/ticket/4919855 )

The idea has been validated based on a substitution variables, which names will start with "ctx:" (the RQL grammar will have to be modified to accept a ":")

This will then allow to write RQL queries like (API still to be tuned):

X owned_by U, U eid %(ctx:cwuser_eid)s

Pyramid

The pyramid-based web server proposed by Christophe and used for its unlish website is still under test and evaluation at Logilab. There are missing features (implemented in cubes) required to be able to deploy pyramid-cubicweb for most of the applications used at Logilab, especially cubicweb-signedrequest

In order to make it possible to implement authentication cubes like cubicweb-signedrequest, the pyramid-cubicweb requires some modifications. These has been developped and are about to be published, along with a new version of signedrequest that provide pyramid compatibility.

There are still some dependencies that lack a proper Debian package, but that should be done in the next few weeks.

In order to properly identify pyramid-related code in a cube, it has been proposed that these code should go in modules in the cube named pviews and pconfig (note that most cube won't require any pyramid specific code). The includeme function should however be in the cube's main packgage (in the init.py file)

There have been some discussions about the fact that, for now, a pyramid-cubicweb instance requires an anonymous user/access, which can also be a problem for some application.

Layout

Christophe pointed the fact that the directory/files layout of cubicweb and cubes do not follow current Python's de facto standards, which makes cubicweb hard to use in a context of virtualenv/pip based installation. There is the CWEP004 discussing some aspects of this problem.

The decision has been taken to move toward a Cubicweb ecosystem that is more pip-friendly. This will be done step by step, starting with the dependencies (packages currently living in the logilab "namespace").

Then we will investigate the feasibility of migrating the layout of Cubicweb itself.

Documentation

The new documentation structure has been approved.

It has been proposed (and more or less accepted) to extract the documentation in a dedicated project. This is not a priority, however.

Roadmap for 3.21

No change since last meeting:

• the complete removal of the dbapi, the merging of Connection and ClientConnection. remains
• Integrate the pyramid cube to provide the pyramid command if the pyramid framework can be imported: removed (too soon, pyramid-cubicweb's APIs are not stable enough)
• Integration of CWEP-003 (FROM clause for RQL): removed (will probably never be included unless someone needs it)
• CWEP-004 (cubes as standard python packages) is being discussed: removed (not for 3.21, see above)

dataimports et stores

A heavy refactoring is under way that concerns data import in CubicWeb. The main goal is to design a single API to be used by the various cubes that accelerate the insertion of data (dataio, massiveimport, fastimport, etc) as well as the internal CWSource and its data feeds.

For details, see the thread on the mailing-list and the patches arriving in the review pipeline.