1. 24 Sep, 2021 1 commit
  2. 14 Sep, 2021 1 commit
  3. 23 Jul, 2021 2 commits
  4. 21 Jul, 2021 1 commit
  5. 24 Jun, 2021 1 commit
  6. 01 Jun, 2021 1 commit
  7. 04 May, 2021 1 commit
  8. 27 Apr, 2021 1 commit
  9. 02 Mar, 2021 3 commits
  10. 20 Apr, 2021 1 commit
  11. 02 Dec, 2020 1 commit
  12. 05 Jan, 2021 1 commit
  13. 02 Mar, 2021 1 commit
  14. 17 Mar, 2020 1 commit
    • Philippe Pepiot's avatar
      [pkg] require python >= 3.4 · 87c3562b3bae
      Philippe Pepiot authored
      This avoid pip pulling a version that does not run on python2 when using a
      python2 environment.
      
      Since we already released some 3.27 releases in pypi, I think we should release
      3.27.3 and remove releases 3.27.2, 3.27.1 and 3.27.0 from pypi.
      
      --HG--
      branch : 3.27
      87c3562b3bae
  15. 14 Feb, 2020 1 commit
  16. 25 Sep, 2020 1 commit
  17. 08 Feb, 2020 1 commit
  18. 04 Dec, 2019 1 commit
  19. 20 Nov, 2019 1 commit
  20. 19 Jun, 2019 1 commit
    • Jérémy Bobbio (Lunar)'s avatar
      [crypto] Use Cryptodome namespace instead of Crypto · 5b0ce10a7046
      Jérémy Bobbio (Lunar) authored
      PyCryptodome comes in two flavors: “an almost drop-in replacement for the old
      PyCrypto library” and “a library independent of the old PyCrypto”. The former
      uses the Crypto namespace, and is shipped as `pycryptodome` while the latter
      uses Cryptodome instead and lies in the `pycryptodomex` package.
      
      Given the reason to switch to PyCryptodome is that PyCrypto in unmaintained,
      its probably better to avoid any mistake and mandate the specific usage of
      the Cryptodome namespace by requiring `pycryptodomex` instead of
      `pycryptodome`.
      
      A more present reason is that Debian buster will only provide a package
      with the separate namespace flavor. The current Recommends is not working with
      the current code. Although it's important to note that the package name will
      probably have to be changed to `python3-pycryptodomex` once
      https://bugs.debian.org/886291 is solved.
      5b0ce10a7046
  21. 21 May, 2019 1 commit
  22. 12 Apr, 2019 1 commit
  23. 05 Apr, 2019 1 commit
    • Denis Laxalde's avatar
      Drop python2 support · 26744ad37953
      Denis Laxalde authored
      This mostly consists in removing the dependency on "six" and updating
      the code to use only Python3 idioms.
      
      Notice that we previously used TemporaryDirectory from
      cubicweb.devtools.testlib for compatibility with Python2. We now
      directly import it from tempfile.
      26744ad37953
  24. 21 Mar, 2019 1 commit
    • Denis Laxalde's avatar
      Remove Twisted web server · 9d88e1177c35
      Denis Laxalde authored
      Twisted web server is not used anymore and has been superseded by
      pyramid many years ago. Furthermore, our usage is not compatible with
      Python 3. So we drop the "etwist" sub-package.
      
      As a consequence, "all-in-one" configuration type gets dropped as it was
      Twisted-specific. We resurrect it in cubicweb/pyramid/config.py by only
      keeping options used by the "pyramid". Similarly, we introduce a
      AllInOneCreateHandler in cubicweb/pyramid/pyramidctl.py that is
      basically the one that lived in cubicweb/etwist/twctl.py and is used to
      create the "all-in-one" instance. Added a TODO here about "pyramid.ini"
      that could be generated at the end of bootstrap() method.
      
      In cubicweb/devtools/httptest.py, CubicWebServerTC is now equivalent to
      CubicWebWsgiTC and the latter is dropped.
      9d88e1177c35
  25. 26 Oct, 2018 1 commit
    • Philippe Pepiot's avatar
      Make test database template creation concurrent · e385c9732f1e
      Philippe Pepiot authored
      build_db_cache() is used in tests to create test database templates, i.e.
      DEFAULT_EMPTY_DB_ID (which is __default_empty_db__) and custom template
      database using CubicwebTC test_db_id/pre_setup_database API.
      
      When running tests in parallel using multiple processes, build_db_cache() may
      try to build the same database twice. Avoid this by adding synchronisation of
      process by using a file lock.
      
      So when two processes require the same template database, one build the
      database and others wait it to be created.
      
      Use filelock (https://github.com/benediktschmitt/py-filelock) library to have a
      portable (unix / windows) way for handling locks.
      Also filelock is packaged in debian: https://packages.debian.org/source/python-filelock
      e385c9732f1e
  26. 15 Feb, 2018 1 commit
  27. 24 Jan, 2018 5 commits
  28. 10 May, 2017 1 commit
  29. 20 Mar, 2017 1 commit
  30. 17 Mar, 2017 2 commits
  31. 28 Feb, 2017 1 commit
    • Denis Laxalde's avatar
      [pyramid] Drop module-level cache and cleanup looping tasks in tools · d432911e3c26
      Denis Laxalde authored
      And use a LRU cache over cached_build_user function.
      
      This looping task is problematic because it would not be run from within a
      WSGI application which does not have a repository with a tasks manager.
      
      This pulls an explicit dependency on 'repoze.lru' but it's not a big deal
      since pyramid already depends on this. RPM spec file not update since it does
      not even mention pyramid...
      d432911e3c26
  32. 21 Feb, 2017 1 commit
    • Denis Laxalde's avatar
      [skeleton,pyramid] Move pyramid app definition in cubicweb.pyramid module · bb0dfc7d2d0e
      Denis Laxalde authored
      The application definition is actually not specific to the final "cube" being
      bootstrapped from skeleton. This patch thus move the pyramid application
      function into cubicweb.pyramid module and let cubicweb register the
      "paste.app_factory" entry point (instead of the bootstrapped cube).
      
      Useless call to `config.scan` is dropped along the way.
      bb0dfc7d2d0e