1. 29 May, 2023 1 commit
  2. 17 May, 2023 3 commits
  3. 15 Feb, 2023 3 commits
  4. 12 May, 2021 6 commits
  5. 11 May, 2021 4 commits
    • Kirill Smelkov's avatar
      Add RELEASING.txt · 4fef1270
      Kirill Smelkov authored
      Add minimal document that describes how to make next zodburi release.
      As suggested by @jamadden zest.releaser, by default, works ok most of the time.
      4fef1270
    • Kirill Smelkov's avatar
      tox += lint · f4ff931f
      Kirill Smelkov authored
      Add minimal linting step that verifies manifest and built sdist/wheel.
      Suggested by @bertjwregeer on https://github.com/Pylons/zodburi/pull/29#issuecomment-836915440.
      f4ff931f
    • Kirill Smelkov's avatar
      Add default MANIFEST.in · f87f1b86
      Kirill Smelkov authored
      While trying to prepare next zodburi release I've noted that the source tarball
      - generated by `python setup.py sdist` or by `python -m build` - is missing some
      files compared to source tarball of previous zodburi release uploaded to PyPI:
      
      https://pypi.org/project/zodburi/2.4.0/#files
      ( https://files.pythonhosted.org/packages/a2/dc/ab3f339d6e123417d7f259a79395a8f6793478d5089886a8b00d186293b1/zodburi-2.4.0.tar.gz )
      
      Many files like CHANGES.rst, contributing.md, CONTRIBUTORS.txt, tox.ini
      and so on were missing:
      
          $ xdiff --stat x/zodburi-2.4.0 zodburi-2.4.1.dev0
          x/zodburi-2.4.0/.gitignore => /dev/null                                   |  14 --
          x/zodburi-2.4.0/.travis.yml => /dev/null                                  |  35 -----
          x/zodburi-2.4.0/CHANGES.rst => /dev/null                                  |  98 ------------
          x/zodburi-2.4.0/CONTRIBUTORS.txt => /dev/null                             | 105 -------------
          x/zodburi-2.4.0/COPYRIGHT.txt => /dev/null                                |   2 -
          {x/zodburi-2.4.0 => zodburi-2.4.1.dev0}/PKG-INFO                          |  17 +-
          x/zodburi-2.4.0/contributing.md => /dev/null                              |  23 ---
          x/zodburi-2.4.0/docs/Makefile => /dev/null                                |  85 ----------
          x/zodburi-2.4.0/docs/api.rst => /dev/null                                 |  10 --
          x/zodburi-2.4.0/docs/conf.py => /dev/null                                 | 205 ------------------------
          x/zodburi-2.4.0/docs/index.rst => /dev/null                               | 385 ----------------------------------------------
          x/zodburi-2.4.0/rtd.txt => /dev/null                                      |   1 -
          {x/zodburi-2.4.0 => zodburi-2.4.1.dev0}/setup.py                          |   7 +-
          x/zodburi-2.4.0/tox.ini => /dev/null                                      |  35 -----
          {x/zodburi-2.4.0 => zodburi-2.4.1.dev0}/zodburi/__init__.py               |   7 +-
          {x/zodburi-2.4.0 => zodburi-2.4.1.dev0}/zodburi/resolvers.py              |  45 ++++++
          {x/zodburi-2.4.0 => zodburi-2.4.1.dev0}/zodburi/tests/test_resolvers.py   | 147 ++++++++++++++----
          {x/zodburi-2.4.0 => zodburi-2.4.1.dev0}/zodburi.egg-info/PKG-INFO         |  17 +-
          {x/zodburi-2.4.0 => zodburi-2.4.1.dev0}/zodburi.egg-info/SOURCES.txt      |  12 --
          {x/zodburi-2.4.0 => zodburi-2.4.1.dev0}/zodburi.egg-info/entry_points.txt |   1 +
          20 files changed, 203 insertions(+), 1048 deletions(-)
      
      -> Fix it by explicitly listing which files need to be distributed in MANIFEST.in
      
      The MANIFEST.in is based on MANIFEST.in from waitress:
      
      https://github.com/Pylons/waitress/blob/master/MANIFEST.in
      
      Not sure how previous source tarballs were prepared - probably it was some kind
      of per-user global MANIFEST being taken on Tres' development machine previously.
      They say explicit is better than implicit anyway...
      
      P.S. I did not included .travis.yml and .gitignore into the MANIFEST because
      those files should not be distributed in tarballs.
      
      /reviewed-by @bertjwregeer
      /reviewed-on https://github.com/Pylons/zodburi/pull/29#issuecomment-836915440
      f87f1b86
    • Kirill Smelkov's avatar
      Garden changelog · c4f00cc2
      Kirill Smelkov authored
      - Both ZODB4/ZODB5 were started to be supported since 7502fa4f (tox tests with zodb4),
      - PyPy started to by supported since 6c46a29d (Added pypy to tox and travis),
      - ``demo:`` URI resolver was added in 2f02bc90 (demo: URI resolver).
      
      Bump next version due to the new features.
      
      /reviewed-by @bertjwregeer
      /reviewed-on https://github.com/Pylons/zodburi/pull/29#issuecomment-836915440
      c4f00cc2
  6. 10 May, 2021 1 commit
  7. 15 Mar, 2021 1 commit
    • Kirill Smelkov's avatar
      demo: URI resolver · 2f02bc90
      Kirill Smelkov authored
      This patch adds `demo:` URI scheme to create DemoStorage from an URI.
      
      While several existing resolvers already handle ?demostorage argument to
      wrap itself with DemoStorage and in-RAM MappingStorage for changes, this
      approach has the following drawbacks:
      
      - every resolver must do it
      - it is not possible to create DemoStorage with non-MappingStorage for changes.
      
      My particular motivation here is Wendelin.core 2: it spawn WCFS
      filesystem server to serve array data from ZODB storage, and passes
      storage URL to spawned wcfs process, so that wcfs could connect and
      retrieve data from the same ZODB storage that client process is
      using. When original ERP5 client is using DemoStorage, both `base` and
      `changes` must be persisted because if changes would be in-RAM
      MappingStorage, WCFS could not access that data because it runs as a
      separate process.
      
      To build a DemoStorage URI we follow XRI Cross-references approach to
      embed URIs for base and changes into combining demo URI:
      
          demo:(base_uri)/(δ_uri)
      
      https://en.wikipedia.org/wiki/Extensible_Resource_Identifier provides
      some related details and examples.
      
      I choose fragments as the place for ZODB.DB arguments:
      
          demo:(base_uri)/(δ_uri)#dbkw...
      
      The reason fragments - instead of parameters - are used, is because
      DB arguments are _local_. Even with different DB arguments the URI
      refers to the same storage, and for wendelin.core 2 it is important to
      be able to determine whether two client processes actually use the same
      underlying ZODB storage, even if those two clients use different local
      parameters, like connection_pool_size and similar. Keeping such local
      arguments in fragments makes it easy to determine the underlying URI of
      the storage - by dropping fragments. It also follows logic from RFC 3986,
      which says that "fragment ... may be ... some view on representations of
      the primary resource": https://tools.ietf.org/html/rfc3986#section-3.5
      
      Thanks beforehand,
      Kirill
      
      /cc @tseaver, @azmeuk, @jimfulton
      
      P.S.
      
      It was already suggested several times to add DemoStorageURIResolver and
      deprecate ?demostorage in existing URI resolvers:
      
      https://github.com/Pylons/zodburi/pull/25#issuecomment-485506959
      https://github.com/Pylons/zodburi/pull/25#issuecomment-511480572
      https://github.com/Pylons/zodburi/pull/25#issuecomment-622931793
      2f02bc90
  8. 02 May, 2020 1 commit
  9. 15 Nov, 2019 1 commit
  10. 14 Nov, 2019 1 commit
  11. 22 Jan, 2019 1 commit
  12. 21 Jan, 2019 1 commit
  13. 18 Jan, 2019 2 commits
  14. 11 Jan, 2019 3 commits
  15. 22 Nov, 2018 1 commit
  16. 20 Nov, 2018 1 commit
  17. 19 Nov, 2018 1 commit
  18. 02 Oct, 2018 8 commits