subscribe to this blog

CubicWeb Blog

News about the framework and its uses.

show 125 results
  • CSS+JS sprint report - Day 1 and 2 (April 2010)

    2010/04/30 by Adrien Di Mascio

    These first two days essentially consisted in exploring the javascript world.

    Documenting javascript

    Sandrine and Alain worked on the javascript documentation tools and how they could be integrated into our sphinx generated documentation.

    http://www.percious.com/static/images/blog/sphinx.png

    They first studied pyjsdoc which unfortunately only generates HTML. After a somewhat successful attempt to generate sphinx ReST, we decided to use a consistent documentation format between python modules and js modules and therefore switched to a home-made, very simple javascript comment parser. Here's an example of what the parser understands:

    /**
     * .. cfunction:: myFunction(a, b, /*...*/, c, d)
     *
     *    This function is very **well** documented and does quite
     *    a lot of stuff :
     *    - task 1
     *    - task 2
     *
     *    :param a: this is the first parameter
     *    ...
     *    :return: 42
     */
    function myFunction(a, b, /*...*/, c, d) {
    }
    

    The extracted ReST snippets are then concatenated and inserted in the general documentation.

    Unit testing javascript

    Katia, Julien and Adrien looked at the different testing tools for javascript, with the two following goals in mind:

    • low-level unit testing, as cubicweb agnostic as possible
    • high-level / functional testing, we want to write navigation scenarios and replay them

    And the two winners of the exploration are:

    http://www.t0asted.com/getwindmill/wm_logo_round.png
    • QUnit for pure javascript / DOM testing. Julien and Adrien successfully managed to test a few cubicweb js functions, most notably the loadxhtml jquery plugin.
    • Windmill for higher level testing. Katia and Sylvain were able to integrate Windmill within the CubicWeb unit testing framework.

    Of course, there is still a lot of work that needs to be done. For instance, we would like to have a test runner facility to run QUnit-based tests on multiple platforms / browsers automatically.

    Parametrized stylesheets and vertical rhythm

    Sylvain worked on property sheets and managed to implement compiled CSS based on simple string interpolation. Of course, compiled CSS are still HTTP cached, automatically recompiled on debug mode, etc. On his way, he also got rid of the external_resources file. Backward compatibility will of course be guaranteed for a while.

    Nicolas worked on CSS and vertical rythm and prepared a patch that introduces a basic rhythm. The tedious work will be to get every stylesheet to dance to the beat.


  • CubicWeb sprint in Paris about js and css

    2010/04/29 by Arthur Lutz

    Logilab is once again hosting a sprint around CubicWeb - 5 days in our Paris offices.

    The general focus will be around javascript & css :

    http://www.iconarchive.com/icons/enhancedlabs/lha-objects/128/Filetype-CSS-icon.pnghttp://codesnip.net/wp-content/uploads/javascript.png
    • easily change the style of an application
    • handling of bundles merging javascript and css
    • have a clean javascript API, documented and tested
    • have documentation about the css & javascript parts in the cubicweb book

    This sprint is taking place from thursday the 29th of April 2010 to the 5th of may 2010 (weekend is off limits - the offices will be closed). You are more than welcome to come along and help out, contribute, or just pair program with someone. Coming only for a day, or an afternoon is fine too... Network resources will be available for those bringing laptops.

    Address : 104 Boulevard Auguste-Blanqui, Paris. Ring "Logilab".

    Metro : St Jacques or Corvisart (Glacière is closest, but will be closed from monday onwards)

    Contact : http://www.logilab.fr/contact

    Dates : 29/04/2010 to 30/04/2010 and 03/05/2010 to 05/05/2010


  • CubicWeb 3.8 released

    2010/04/28 by Sylvain Thenault

    CubicWeb 3.8.0 went out last week, but now we have tested it, produced a 3.8.1, it's show time!

    What's new in CubicWeb 3.8?

    One of the most important change is http server update to move from deadend twisted.web2 to twisted.web. With this change comes the possibility to configure the maximum size of POST request in the configuration file (was hard-coded to 100Mo before).

    Other changes include:

    • CubicWeb should now be installable through pip or easy_install. This is still experimental, and we don't use it that much so please, give us some feedback! Some cubes are now also "pipable" (comment, blog...), but more will come with new releases.
    • .execute() function lost its cache key argument. This is great news since it was a pain to explain and most cubicweb users didn't know how to handle it well (and I'm thre greatest beneficer since I won't have to explain over and over again)
    • nicer schema and workflow views
    • refactored web session handling, which should now be cleaner, clearer, hence less buggy...
    • nicer skeleton generation for new cubes, cleaner __pkginfo__ (you don't have to define both __depends__ / __depends_cubes__ or __recommends__ / __recommends_cubes__ in the general case, and other cleanups)

    Enjoy!


  • Migrating cubicweb instances - benefits from a distributed architecture

    2010/04/22 by Arthur Lutz

    Aim : do the migration for N cubicweb instances hosted on a server to another with no downtime.

    Prerequisites : have an explicit definition of the database host (not default or localhost). In our case, the database is hosted on another host. You are not migrating your pyro server. You are not using multisource (more documentation on that soon).

    Steps :

    1. on new machine : install your environment (pseudocode)

      apt-get install cubicweb cubicweb-applications apache2
      
    2. on old machine : copy your cubicweb and apache configuration to the new machine

      scp /etc/cubicweb.d/ newmachine:/etc/cubicweb.d/
      scp /etc/apache2/sites-available/ newmachine:/etc/apache2/sites-available/
      
    3. on new machine : give new ids to pyro registration so the new instances can register

      cd /etc/cubicweb.d/ ; sed -i.bck 's/^pyro-instance-id=.*$/\02/' */all-in-one.conf
      
    4. on new machine : start your instances

      cubicweb start
      
    5. on new machine : enable sites and modules for apache and start it, test it using by modifying your /etc/host file.

    6. change dns entry from your oldmachine to newmachine

    7. shutdown your old machine (if it doesn't host other services or your database)

    8. That's it.

    Possible enhancements : use right from the start a pound server behind your apache, that way you can add backends and smoothily migrate by shuting down backends that pound will take into account.

    http://www.cubicweb.org/image/893561?vid=download

  • Documentation progress

    2010/04/20 by Aurelien Campeas

    As part of an effort to improve the documentation (see the cw_course version) a lot of chapters have been completed (and filled with real-world examples). Many more were updated and reorganized.

    I won't list everything but here are the most important improvements:

    picture under creative commons

    Picture under Creative Commons, courtesy of digitalnoise.

    • The publishing process
    • Templates & the architecture of views
    • Primary views customizations (including use of the uicfg module)
    • Controllers
    • Hooks & Operations
    • Proper usage of the ORM
    • Unit tests
    • Breadcrumbs
    • URL rewrite
    • Using the CW javascript library

    Last but not least, a whole new tutorial based on Sylvain's great series Building my photos Web site has been included. It covers some advanced topics such as Operations and sophisticated security settings.

    The visual style has been enhanced a bit to have better readability.

    As always, patches are welcome !

    picture under Creative Commons, courtesy of digitalnoise


  • Building my photos web site with CubicWeb part II: security, testing and migration

    2010/04/13 by Sylvain Thenault

    This post will cover various topics:

    • configuring security
    • migrating an existing instance
    • writing some unit tests

    Goal

    Here are the read permissions I want:

    • folders, files, images and comments should have one of the following visibility rules:
      • 'public', everyone can see it
      • 'authenticated', only authenticated users can see it
      • 'restricted', only a subset of authenticated users can see it
    • managers (e.g. me) can see everything
    • only authenticated users can see people
    • everyone can see classifier entities (tag and zone)

    Also, unless explicity specified, the visibility of an image should be the same as the visibility of its parent folder and the visibility of a comment should be the same as the one of the commented entity. If there is no parent entity, the default visibility is 'authenticated'.

    Regarding write permissions, that's much easier:

    • the anonymous user can't write
    • authenticated users can only add comment
    • managers will add the remaining stuff

    Now, let's implement that!

    Proper security in CubicWeb is done at the schema level, so you don't have to bother with it in the views, for the users will only see what they have access to.

    Step 1: adding permissions to the schema

    In the schema, you can grant access according to groups or RQL expressions (users get access if the expression return some results). To implements the read security defined above, groups are not enough, we'll need to use RQL expressions. Here is the idea:

    • add a visibility attribute on folder, image and comment, with a vocabulary ('public', 'authenticated', 'restricted', 'parent')
    • add a may_be_read_by relation that links folder, image or comment to users,
    • add hooks to propagate permission changes.

    So the first thing to do is to modify the schema.py of my cube to define these relations:

    from yams.constraints import StaticVocabularyConstraint
    
    class visibility(RelationDefinition):
        subject = ('Folder', 'File', 'Image', 'Comment')
        object = 'String'
        constraints = [StaticVocabularyConstraint(('public', 'authenticated',
                                                   'restricted', 'parent'))]
        default = 'parent'
        cardinality = '11' # required
    
    class may_be_read_by(RelationDefinition):
        subject = ('Folder', 'File', 'Image', 'Comment',)
        object = 'CWUser'
    

    We can note the following points:

    • we've added a new visibility attribute to folder, file, image and comment using a RelationDefinition
    • cardinality = '11' means this attribute is required. This is usually hidden under the required argument given to the String constructor, but we can rely on this here (same thing for StaticVocabularyConstraint, which is usually hidden by the vocabulary argument)
    • the 'parent' possible value will be used for visibility propagation

    Now, we should be able to define security rules in the schema, based on these new attribute and relation. Here is the code to add to schema.py:

    from cubicweb.schema import ERQLExpression
    
    VISIBILITY_PERMISSIONS = {
        'read':   ('managers',
                   ERQLExpression('X visibility "public"'),
                   ERQLExpression('X visibility "authenticated", U in_group G, G name "users"'),
                   ERQLExpression('X may_be_read_by U')),
        'add':    ('managers',),
        'update': ('managers', 'owners',),
        'delete': ('managers', 'owners'),
        }
    AUTH_ONLY_PERMISSIONS = {
            'read':   ('managers', 'users'),
            'add':    ('managers',),
            'update': ('managers', 'owners',),
            'delete': ('managers', 'owners'),
            }
    CLASSIFIERS_PERMISSIONS = {
            'read':   ('managers', 'users', 'guests'),
            'add':    ('managers',),
            'update': ('managers', 'owners',),
            'delete': ('managers', 'owners'),
            }
    
    from cubes.folder.schema import Folder
    from cubes.file.schema import File, Image
    from cubes.comment.schema import Comment
    from cubes.person.schema import Person
    from cubes.zone.schema import Zone
    from cubes.tag.schema import Tag
    
    Folder.__permissions__ = VISIBILITY_PERMISSIONS
    File.__permissions__ = VISIBILITY_PERMISSIONS
    Image.__permissions__ = VISIBILITY_PERMISSIONS
    Comment.__permissions__ = VISIBILITY_PERMISSIONS.copy()
    Comment.__permissions__['add'] = ('managers', 'users',)
    Person.__permissions__ = AUTH_ONLY_PERMISSIONS
    Zone.__permissions__ = CLASSIFIERS_PERMISSIONS
    Tag.__permissions__ = CLASSIFIERS_PERMISSIONS
    

    What's important in there:

    • VISIBILITY_PERMISSIONS provides read access to an entity:
      • if user is in the 'managers' group,
      • or if visibility attribute's value is 'public',
      • or if visibility attribute's value is 'authenticated' and user (designed by the 'U' variable in the expression) is in the 'users' group (all authenticated users are expected to be in this group)
      • or if user is linked to the entity (the 'X' variable) through the may_be_read_by permission
    • we modify permissions of the entity types we use by importing them and modifying their __permissions__ attribute
    • notice the .copy(): we only want to modify 'add' permission for Comment, not for all entity types using VISIBILITY_PERMISSIONS!
    • remaning parts of the security model is done using regular groups:
      • 'users' is the group to which all authenticated users will belong
      • 'guests' is the group of anonymous users

    Step 2: security propagation in hooks

    To fullfill our requirements, we have to implement:

    Also, unless explicity specified, the visibility of an image should be the same as
    the visibility of its parent folder and the visibility of a comment should be the same as the
    one of the commented entity. If there is no parent entity, the default visibility is
    'authenticated'.
    

    This kind of 'active' rule will be done using CubicWeb's hook system. Hooks are triggered on database event such as addition of new entity or relation.

    The tricky part of the requirement is in unless explicitly specified, notably because when the entity addition hook is executed, we don't know yet its 'parent' entity (eg folder of an image, image commented by a comment). To handle such things, CubicWeb provides Operation, which allow to schedule things to do at commit time.

    In our case we will:

    • on entity creation, schedule an operation that will set default visibility
    • when a "parent" relation is added, propagate parent's visibility unless the child already has a visibility set

    Here is the code in cube's hooks.py:

    from cubicweb.selectors import implements
    from cubicweb.server import hook
    
    class SetVisibilityOp(hook.Operation):
        def precommit_event(self):
            for eid in self.session.transaction_data.pop('pending_visibility'):
                entity = self.session.entity_from_eid(eid)
                if entity.visibility == 'parent':
                    entity.set_attributes(visibility=u'authenticated')
    
    class SetVisibilityHook(hook.Hook):
        __regid__ = 'sytweb.setvisibility'
        __select__ = hook.Hook.__select__ & implements('Folder', 'File', 'Image', 'Comment')
        events = ('after_add_entity',)
        def __call__(self):
            hook.set_operation(self._cw, 'pending_visibility', self.entity.eid,
                               SetVisibilityOp)
    
    class SetParentVisibilityHook(hook.Hook):
        __regid__ = 'sytweb.setparentvisibility'
        __select__ = hook.Hook.__select__ & hook.match_rtype('filed_under', 'comments')
        events = ('after_add_relation',)
    
        def __call__(self):
            parent = self._cw.entity_from_eid(self.eidto)
            child = self._cw.entity_from_eid(self.eidfrom)
            if child.visibility == 'parent':
                child.set_attributes(visibility=parent.visibility)
    

    Remarks:

    • hooks are application objects, hence have selectors that should match entity or relation type to which the hook applies. To match relation type, we use the hook specific match_rtype selector.
    • usage of set_operation: instead of adding an operation for each added entity, set_operation allows to create a single one and to store the eids of the entities to be processed in the session transaction data. This is a good pratice to avoid heavy operations manipulation cost when creating a lot of entities in the same transaction.
    • the precommit_event method of the operation will be called at transaction's commit time.
    • in a hook, self._cw is the repository session, not a web request as usually in views
    • according to hook's event, you have access to different member on the hook instance. Here:
      • self.entity is the newly added entity on 'after_add_entity' events
      • self.eidfrom / self.eidto are the eid of the subject / object entity on 'after_add_relation' events (you may also get the relation type using self.rtype)

    The 'parent' visibility value is used to tell "propagate using parent security" because we want that attribute to be required, so we can't use None value else we'll get an error before we get any chance to propagate...

    Now, we also want to propagate the may_be_read_by relation. Fortunately, CubicWeb provides some base hook classes for such things, so we only have to add the following code to hooks.py:

    # relations where the "parent" entity is the subject
    S_RELS = set()
    # relations where the "parent" entity is the object
    O_RELS = set(('filed_under', 'comments',))
    
    class AddEntitySecurityPropagationHook(hook.PropagateSubjectRelationHook):
        """propagate permissions when new entity are added"""
        __regid__ = 'sytweb.addentity_security_propagation'
        __select__ = (hook.PropagateSubjectRelationHook.__select__
                      & hook.match_rtype_sets(S_RELS, O_RELS))
        main_rtype = 'may_be_read_by'
        subject_relations = S_RELS
        object_relations = O_RELS
    
    class AddPermissionSecurityPropagationHook(hook.PropagateSubjectRelationAddHook):
        __regid__ = 'sytweb.addperm_security_propagation'
        __select__ = (hook.PropagateSubjectRelationAddHook.__select__
                      & hook.match_rtype('may_be_read_by',))
        subject_relations = S_RELS
        object_relations = O_RELS
    
    class DelPermissionSecurityPropagationHook(hook.PropagateSubjectRelationDelHook):
        __regid__ = 'sytweb.delperm_security_propagation'
        __select__ = (hook.PropagateSubjectRelationDelHook.__select__
                      & hook.match_rtype('may_be_read_by',))
        subject_relations = S_RELS
        object_relations = O_RELS
    
    • the AddEntitySecurityPropagationHook will propagate the relation when filed_under or comments relations are added
      • the S_RELS and O_RELS set as well as the match_rtype_sets selector are used here so that if my cube is used by another one, it'll be able to configure security propagation by simply adding relation to one of the two sets.
    • the two others will propagate permissions changes on parent entities to children entities

    Step 3: testing our security

    Security is tricky. Writing some tests for it is a very good idea. You should even write them first, as Test Driven Development recommends!

    Here is a small test case that'll check the basis of our security model, in test/unittest_sytweb.py:

    from cubicweb.devtools.testlib import CubicWebTC
    from cubicweb import Binary
    
    class SecurityTC(CubicWebTC):
    
        def test_visibility_propagation(self):
            # create a user for later security checks
            toto = self.create_user('toto')
            # init some data using the default manager connection
            req = self.request()
            folder = req.create_entity('Folder',
                                       name=u'restricted',
                                       visibility=u'restricted')
            photo1 = req.create_entity('Image',
                                       data_name=u'photo1.jpg',
                                       data=Binary('xxx'),
                                       filed_under=folder)
            self.commit()
            photo1.clear_all_caches() # good practice, avoid request cache effects
            # visibility propagation
            self.assertEquals(photo1.visibility, 'restricted')
            # unless explicitly specified
            photo2 = req.create_entity('Image',
                                       data_name=u'photo2.jpg',
                                       data=Binary('xxx'),
                                       visibility=u'public',
                                       filed_under=folder)
            self.commit()
            self.assertEquals(photo2.visibility, 'public')
            # test security
            self.login('toto')
            req = self.request()
            self.assertEquals(len(req.execute('Image X')), 1) # only the public one
            self.assertEquals(len(req.execute('Folder X')), 0) # restricted...
            # may_be_read_by propagation
            self.restore_connection()
            folder.set_relations(may_be_read_by=toto)
            self.commit()
            photo1.clear_all_caches()
            self.failUnless(photo1.may_be_read_by)
            # test security with permissions
            self.login('toto')
            req = self.request()
            self.assertEquals(len(req.execute('Image X')), 2) # now toto has access to photo2
            self.assertEquals(len(req.execute('Folder X')), 1) # and to restricted folder
    
    if __name__ == '__main__':
        from logilab.common.testlib import unittest_main
        unittest_main()
    

    It is not complete, but it shows most of the things you will want to do in tests: adding some content, creating users and connecting as them in the test, etc...

    To run it type:

    [syt@scorpius test]$ pytest unittest_sytweb.py
    ========================  unittest_sytweb.py  ========================
    -> creating tables [....................]
    -> inserting default user and default groups.
    -> storing the schema in the database [....................]
    -> database for instance data initialized.
    .
    ----------------------------------------------------------------------
    Ran 1 test in 22.547s
    
    OK
    

    The first execution is taking time, since it creates a sqlite database for the test instance. The second one will be much quicker:

    [syt@scorpius test]$ pytest unittest_sytweb.py
    ========================  unittest_sytweb.py  ========================
    .
    ----------------------------------------------------------------------
    Ran 1 test in 2.662s
    
    OK
    

    If you do some changes in your schema, you'll have to force regeneration of that database. You do that by removing the tmpdb* files before running the test:

    [syt@scorpius test]$ rm tmpdb*
    

    BTW, pytest is a very convenient utilities to control test execution, from the logilab-common package.

    Step 4: writing the migration script and migrating the instance

    Prior to those changes, Iv'e created an instance, fed it with some data, so I don't want to create a new one, but to migrate the existing one. Let's see how to do that.

    Migration commands should be put in the cube's migration directory, in a file named file:<X.Y.Z>_Any.py ('Any' being there mostly for historical reason).

    Here I'll create a migration/0.2.0_Any.py file containing the following instructions:

    add_relation_type('may_be_read_by')
    add_relation_type('visibility')
    sync_schema_props_perms()
    

    Then I update the version number in cube's __pkginfo__.py to 0.2.0. And that's it! Those instructions will:

    • update the instance's schema by adding our two new relations and update the underlying database tables accordingly (the two first instructions)
    • update schema's permissions definition (the later instruction)

    To migrate my instance I simply type:

    [syt@scorpius ~]$ cubicweb-ctl upgrade sytweb
    

    I will then be asked some questions to do the migration step by step. You should say YES when it asks if a backup of your database should be done, so you can get back to the initial state if anything goes wrong...

    Conclusion

    This is a somewhat long post that I bet you will have to read at least twice ;) There is a hell lot of information hidden in there... But that should start to give you an idea of CubicWeb's power...

    See you next time for part III !


  • Building my photos web site with CubicWeb (Part I)

    2010/04/01 by Sylvain Thenault

    Desired features

    • photo gallery;
    • photo stored onto the fs and displayed through a web interface dynamically;
    • navigation through folder (album), tags, geographical zone, people on the picture... using facets;
    • advanced security (eg not everyone can see everything). More on this later.

    Let's go then

    Step 1: creating a new cube for my web site

    One note about my development environment: I wanted to use packaged version of CubicWeb and cubes while keeping my cube in my user directory, let's say ~src/cubes. It can be done by setting the following environment variables:

    CW_CUBES_PATH=~/src/cubes
    CW_MODE=user
    

    The new cube, holding custom code for this web site, can now be created using:

    cubicweb-ctl newcube --directory=~/src/cubes sytweb
    

    Step 2: pick building blocks into existing cubes

    Almost everything I want to represent in my web-site is somewhat already modelized in existing cubes that I'll extend for my needs:

    • folder, containing Folder entity type, which will be used as both 'album' and a way to map file system folders. Entities are added to a given folder using the filed_under relation.
    • file, containing File and Image entity type, gallery view, and a file system import utility.
    • zone, containing the Zone entity type for hierarchical geographical zones. Entities (including sub-zones) are added to a given zone using the situated_in relation.
    • person, containing the Person entity type plus some basic views.
    • comment, providing a full commenting system allowing one to comment entity types supporting the comments relation by adding a Comment entity.
    • tag, providing a full tagging system as an easy and powerful way to classify entities supporting the tags relation by linking the to Tag entities. This will allow navigation into a large number of pictures.

    Ok, now I'll tell my cube requires all this by editing cubes/sytweb/__pkginfo__.py:

    __depends_cubes__ = {'file': '>= 1.2.0',
                         'folder': '>= 1.1.0',
                         'person': '>= 1.2.0',
                         'comment': '>= 1.2.0',
                         'tag': '>= 1.2.0',
                         'zone': None,
                         }
    __depends__ = {'cubicweb': '>= 3.5.10',
                   }
    for key,value in __depends_cubes__.items():
        __depends__['cubicweb-'+key] = value
    __use__ = tuple(__depends_cubes__)
    

    Notice that you can express minimal version of the cube that should be used, None meaning whatever version available.

    Step 3: glue everything together in my cube's schema

    from yams.buildobjs import RelationDefinition
    
    class comments(RelationDefinition):
        subject = 'Comment'
        object = ('File', 'Image')
        cardinality = '1*'
        composite = 'object'
    
    class tags(RelationDefinition):
        subject = 'Tag'
        object = ('File', 'Image')
    
    class filed_under(RelationDefinition):
        subject = ('File', 'Image')
        object = 'Folder'
    
    class situated_in(RelationDefinition):
        subject = 'Image'
        object = 'Zone'
    
    class displayed_on(RelationDefinition):
        subject = 'Person'
        object = 'Image'
    

    This schema:

    • allows to comment and tag File and Image entity types by adding the comments and tags relations. This should be all we have to do for this feature since the related cubes provide 'pluggable section' which are automatically displayed in the primary view of entity types supporting the relation.
    • adds a situated_in relation definition so that image entities can be geolocalized.
    • add a new relation displayed_on relation telling who can be seen on a picture.

    This schema will probably have to evolve as time goes (for security handling at least), but since the possibility to change and update the schema evolving is one of CubicWeb features (and goals), we won't worry and see that later when needed.

    Step 4: creating the instance

    Now that I have a schema, I want to create an instance of that new 'sytweb' cube, so I run:

    cubicweb-ctl create sytweb sytweb_instance
    

    hint: if you get an error while the database is initialized, you can avoid having to reanswer to questions by running

    cubicweb-ctl db-create sytweb_instance
    

    This will use your already configured instance and start directly from the database creation step, thus skipping questions asked by the 'create' command.

    Once the instance and database are fully initialized, run

    cubicweb-ctl start sytweb_instance
    

    to start the instance, check you can connect on it, etc...

    Next times

    We will customize the index page, see security configuration, use the Bytes FileSystem Storage... Lots of cool stuff remaining :)

    Next post : security, testing and migration


  • Fun with graphs in apycot

    2010/03/24 by Arthur Lutz

    Yesterday I had a little quick fun with apycot in the train, using the existing plots infrastructure I managed to quickly add a few graphs to the application. I only had an old dump of our apycot for mercurial (http://apycot.hg-scm.org/) so the timespan is not huge, but I like it anyway! Here are some dev screenshots while you wait for this feature your your application... The pylint grades where pretty constant so I'm not including that graph.

    http://www.cubicweb.org/image/779761?vid=downloadhttp://www.cubicweb.org/image/779768?vid=download

    Now, I have to make solid code and integrate it properly.


  • CubicWeb 3.7 released

    2010/03/19

    Hi there !

    I'm pleased to announce the 3.7 release of CubicWeb, after a much shorter development cycle than for the 3.6...

    But it still have some interesting changes:

    • NOW DEPENDS ON PYTHON 2.5
    • use the newly created logilab.database package (you'll have to install it as well as upgrade logilab.common and rql)
    • proper behaviour on the repository side of cubiweb:
      • dropped unsafe_execute, execute is now unsafe by default in hooks and operations. You can still explicitly control security using the enabled_secury context manager
      • proper transaction hooks control using the hooks_control context manager
    • started some transaction undo support (only undo of deletion supported right now)
    • various other bug fixes and improvments

    Notice the 3.6 branch will still be maintained for some time.

    Enjoy!


  • Continuous Integration platform for Mercurial with apycot

    2010/03/15 by Arthur Lutz

    Since the mercurial 1.5 sprint Pierre-Yves has been working on improving Continuous Integration for Mercurial. All developers are encouraged to run the test suites and code quality checkers but it's no always feasible to test every cases, different OS, different python versions, strange test dependencies, slow coverage run, etc. Moreover it's generally useful to keep track of the results of previous tests, especially for benchmarks.

    At http://apycot.hg-scm.org/ you will find a production setup that now runs several variants of the tests-suite for all official repo and checks code style and documentation. Notification by email or RSS is available. For more details check out the FAQ.

    apycot is open source and uses the cubicweb platform, if you want to set up one for your project, check out the step by step documentation.

    http://www.cubicweb.org/image/749160?vid=download

show 125 results