[Bug 1282311] Re: [FFe] libclick

[Launchpad Bug Tracker]

This bug was fixed in the package click - 0.4.17.2

---------------
click (0.4.17.2) trusty; urgency=medium

  [ Colin Watson ]
  * Fix Click.User construction in "click pkgdir".

click (0.4.17.1) trusty; urgency=medium

  * gobject-introspection-1.0.pc is in libgirepository1.0-dev, not
    gobject-introspection.  Fix Build-Depends.
  * Build-depend and depend on gir1.2-glib-2.0 and python3-gi.
  * Map gboolean to ctypes.c_int, not ctypes.c_bool.  gboolean and gint are
    the same as far as glib is concerned, and ctypes does strange things
    with its bool type in callbacks.

click (0.4.17) trusty; urgency=medium

  * Use full path to click in Upstart jobs to save a $PATH lookup.
  * Add systemd units to run Click system and user hooks at the appropriate
    times.  We probably won't be using these for a while, but it does no
    harm to add them.
  * Move an initial core of functionality (database, hooks, osextras, query,
    user) from Python into a new "libclick" library, allowing
    performance-critical clients to avoid the cost of starting a new Python
    interpreter (LP: #1282311).
 -- Ubuntu daily release <ps-jenkins at lists.canonical.com>   Thu, 06 Mar 2014 16:38:35 +0000

** Changed in: click (Ubuntu)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1282311

Title:
  [FFe] libclick

Status in “click” package in Ubuntu:
  Fix Released

Bug description:
  I initially wrote click in Python in order to be able to get it up and
  running quickly.  I still think Python is appropriate for large chunks
  of it, particularly the parts that are only run by developers ("click
  build", "click chroot", etc.), but it is not ideal to have to go
  through Python in resource-constrained environments such as phones.
  When we start up Ubuntu Touch in an ARM emulator, it takes a very long
  time to run all the click hooks, which directly affects how quickly we
  can turn round CI tests; and I've also heard that various queries from
  desktop infrastructure currently made by way of running click as a
  subprocess can contribute as much as a second to application startup
  time.  This is obviously unacceptable and we need to do something
  about it.

  Not wanting to do a scorched-earth rewrite, my approach to this is to
  rewrite hot parts of click in Vala (previously C, but I found that I
  was writing too much error handling boilerplate by hand and Vala has
  the right layer of abstraction here) and expose them as a "libclick"
  library, using GObject in order to gain introspection support and thus
  trivially have Python bindings available.  This will allow me to
  translate things gradually, and in particular it will let me leave the
  existing rather comprehensive test suite in place with only minimal
  adjustments, which will provide quite good assurance that I haven't
  broken anything too seriously.  By itself, it may well not speed
  things up very much as the top-level /usr/bin/click program will still
  be a Python script (at least for the moment), but we will be able to
  gain significant improvements to application startup time shortly
  afterwards with a few very small changes to packages such as upstart-
  app-launch.

  I had hoped to have an initial version of this in place well before
  feature freeze, and have been coding frenetically over the last week
  to try to achieve that.  Unfortunately, the basic query functionality
  that's top of the list for libclick requires essentially the whole
  interwoven edifice of click.{database,hooks,user}, which is around
  1000 lines of Python code, turning into around 2500 lines of Vala (it
  would have been more like 5000 lines of C).  If I were able to
  separate out any particularly useful subset of this, I would, but I
  don't think it's realistic.  I also don't want to try to rush a
  landing given how critical it is to the phone.

  As such, I'd like to apply for a feature freeze exception for the work
  described here.  Based on my current rate of progress, I expect to
  have something worth landing by around the end of next week.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/click/+bug/1282311/+subscriptions