1. 28 Sep, 2017 1 commit
  2. 06 Jul, 2017 2 commits
    • Mathieu Bridon's avatar
      Upgrade our dependencies · 32cfe4c9
      Mathieu Bridon authored
    • Mathieu Bridon's avatar
      Get the tests to display warnings · fbb23412
      Mathieu Bridon authored
      Since its 1.11 release, Django doesn't report deprecation warnings any
      more by default. This means we missed some after the upgrade.
      It is especially bad because Django 2.0 will break a lot of things, and
      Django 1.11 is meant as a stepping stone towards that, adding lots of
      deprecationw warnings to help migrate to 2.0.
      With pytest 3.1, we can control finely what warnings we want to display,
      or even whether they should be considered failures. Upgrading makes it
      trivial to display the deprecation warnings.
      In this way, the CI will help us move towards Django 2.0, or even
      upgrade any of our dependencies which handle compatibility breaks with
      deprecation periods, the way Django does.
      Relates to #817
  3. 11 May, 2017 2 commits
    • Mathieu Bridon's avatar
      Stop explicitly depending on html5lib from git · e7d2d9d7
      Mathieu Bridon authored
      We had to do that so we would get a newer html5lib which had dropped its
      dependency on setuptools, as that cause issues with our usage of
      But since pip-tools 1.9.0, we don't need to do that any more:
      pip-compile now properly excludes setuptools and its dependencies.
      We don't use html5lib directly, it is a transitive dependency through
      bleach, so we can now completely remove it from our requirements.in file
      and let pip-compile do its magic.
    • Mathieu Bridon's avatar
      Upgrade our dependencies · 41d10c10
      Mathieu Bridon authored
  4. 05 May, 2017 2 commits
  5. 27 Apr, 2017 3 commits
    • Mathieu Bridon's avatar
      Move to Django 1.11 · 2c35a8e6
      Mathieu Bridon authored
      One of the major new things introduced in Django 1.11 is template-based
      rendering for widgets.
      As a result, our custom LangSelect widget needs to be adapted to the
      The old render_option method now becomes simply a local option template.
      The old render_options method however is a bit more complex, and we need
      to move its filtering to the new optgroups method.
    • Mathieu Bridon's avatar
      Upgrade most of our dependencies · 003cd917
      Mathieu Bridon authored
      Django 1.11 is a bit of a bigger fish to fry, so it's going to come in
      its own commit.
    • Mathieu Bridon's avatar
      Explicitly add typing as a dependency · a594f89d
      Mathieu Bridon authored
  6. 13 Apr, 2017 1 commit
    • Mathieu Bridon's avatar
      We're not blocked on an old dbus-python any more · 8bb8cebc
      Mathieu Bridon authored
      We had to use such an old version because our Ci was running on an old
      Ubuntu in Travis.
      But now that we're running the CI on Debian Jessie, we can move to the
      latest dbus-python release without any problem.
  7. 06 Apr, 2017 2 commits
    • Matthieu Gautier's avatar
      Add support for tinymce widget. · 6b32edf4
      Matthieu Gautier authored
      There are some things to respect :
      - In a form, only `input` or `textarea` are send into a request to the server.
        So we must have a input using the same name of the widget.
      - If we want to use tinymce inline (without iframe), we need to use a
        block element. So we cannot use a `input` or a `textarea`.
        In our case we use a `div`
      Tinymce is aware of this problem and do two things :
      - By default it creates a input associated to the `div`.
        The input will (and must) have for `name` the `id` of the `div`
      - When tinymce saves (before form send) it copy the content of the `div`
        into the value of the input using the association `name`<->`id` to find
        which input to set.
      Last trick, we need all this thing to still work without js because we use
      form to validate data (in import_media) and also for unit tests. So the
      name of the input must be `name` given as argument to `render`
    • Mathieu Bridon's avatar
      Downgrade our python-NetworkManager dependency · 9cfb2f5d
      Mathieu Bridon authored
      The latest releases are giving us trouble. Version 2.0.0 is a full
      rewrite, which seems to have broken compatibility with the old
      NetworkManager on Debian Jessie.
      Git master has a patch to restore compatibility:
      However, even with that applied we still seem to encounter issues. So
      for now, we've decided to stick with the older version.
  8. 17 Mar, 2017 1 commit
  9. 02 Mar, 2017 3 commits
  10. 24 Feb, 2017 1 commit
    • Matthieu Gautier's avatar
      Remove -e in requirements(-dev).txt · 302c66d0
      Matthieu Gautier authored
      pip-compile doesn't support URLs as packages unless they are editable.
      So we need the '-e' options in *.in files.
      But, then when dh-virtualenv	install the package as editable with a
      egg-link pointing to the source. As the sources change location when we
      package everything, the egg-link points to nothing and we cannot import
      the packages.
      This is a bit silly, but the sed after the requirements.txt generation
      removes the '-e' option and everything work again.
      This is definitively a workaround and we should remove it once this bug is
      fixed : https://github.com/spotify/dh-virtualenv/issues/200
  11. 16 Feb, 2017 2 commits
    • Mathieu Bridon's avatar
      Handle our dependencies with pip-tools · 7f168b67
      Mathieu Bridon authored
      This is pretty nifty.
      Keeping our dependencies up to date is as simple as running:
          make upgrade-deps
      And it generates **complete** pip requirements files, so that we know
      exactly what gets installed, everybody (including the Debian packages)
      gets the same versions of everything, no matter when they installed.
      If we need to add a new dependency, or remove an old one, we do that in
      the new .in files.
      And from time to time, each one of us needs to sync their virtual
          make sync-deps
      More details about pip-tools:
    • Mathieu Bridon's avatar
      Use the standard unittest.mock module · 9e0118ba
      Mathieu Bridon authored
      We rely on Python >= 3.4, and the mock module was merged in the standard
      library with Python 3.3.
  12. 06 Jan, 2017 1 commit
    • Mathieu Bridon's avatar
      flakes: Ask pytest to run pyflakes · 3afdc12f
      Mathieu Bridon authored
      The previous commits in this branch fixed all the issues pyflakes could
      Asking pytest to always run it will help us make sure we don't ever
      introduce new issues of this kind.
  13. 05 Jan, 2017 1 commit
  14. 24 Nov, 2016 1 commit
  15. 17 Nov, 2016 1 commit
  16. 03 Nov, 2016 1 commit
  17. 30 Sep, 2016 1 commit
  18. 09 Sep, 2016 1 commit
  19. 25 Jul, 2016 1 commit
  20. 22 Jul, 2016 1 commit
    • Mathieu Bridon's avatar
      Add an in-db configuration management system · 3009e687
      Mathieu Bridon authored
      We're going to move stuff from the settings file to forms in the admin
      UI, so we'll need to store configuration into the database.
      This introduces a new model that just that.
      Each entry in the table is a configuration option. It has:
      * A `namespace`, to group together settings related to a particular part
        of ideascube. For example, settings related to the media center would
        all have the `namespace` set to the 'mediacenter' string.
      * A `key`, which is the setting name. For example, the configuration
        option to control the site name could have its `key` set to the
        'site-name' string.
      * A `value`, which is the configuration value. It could be anything, as
        long as it is JSON-serializable, as that's how it gets stored in the
      * An `actor`, which the person from the staff who made the configuration
      * A `date`, which is the datetime at which the configuration change
      I'm adding a convenience API with `set`, which allows to easily set the
      value of a setting, whether it already exists or not, abstracting the
      underlying model API.
      I'm also adding another convenience API with `get_string`, which allows
      to get the value of a setting, eventually providing a default value.
      I'm only adding this for string settings, because that's all I'm going
      to use in the short term, adding similar ones for other types is left as
      an exercise for those who will need them in the future.
      Implements #404
  21. 21 Jul, 2016 1 commit
  22. 23 May, 2016 1 commit
  23. 10 Apr, 2016 1 commit
  24. 30 Mar, 2016 1 commit
  25. 03 Mar, 2016 1 commit
  26. 13 Feb, 2016 1 commit
  27. 18 Dec, 2015 1 commit
  28. 25 Nov, 2015 1 commit
  29. 17 Nov, 2015 1 commit
  30. 07 Nov, 2015 1 commit
  31. 25 Oct, 2015 1 commit