1. 04 Apr, 2018 1 commit
    • Jérome Perrin's avatar
      slapos-testing: rework to use buildout to install eggs and dependencies · c91c4722
      Jérome Perrin authored
      Instead of letting `python setup.py test` install the depencies, use
      buildout way of installing the eggs.
      
      This software use `interpreter` recipe of `zc.recipe.egg` to install a
      python with all eggs pre-installed. This is a way to get all the
      dependencies at install time instead of getting them at run time from
      pypi when running `python setup.py test`.
      `erp5.util.testsuite` has been extended to support a parameter to
      specify which python interpreter to use.
      
      One issue is that this way of installing eggs by buildout cause chicken
      and egg problem: cloning repository containing `slapos.recipe.cmmi`
      needs git, and to compiling git needs `slapos.recipe.cmmi`.
      The consequence of this is that re-running software will install too
      many parts again.
      One solution for this would be to clone `slapos.recipe.cmmi` with a
      `git` command provided by testnode or system package.
      Another solution would be to not install `slapos.recipe.cmmi` develop
      egg, simply install the egg from it's current pypi version while
      installing the software (running tests will be from the git checkout
      anyway).
      For now this is open issue.
      
      Another point of attention is that `python setup.py test` install the
      requirements listed in `test_requires`, but `zc.recipe.egg` does not
      provide a way of installing these. Some of our packages have `[test]`
      entrypoints, in this case, the software installs the test entrypoints.
      For others, we install the eggs.
      
      Other improvements:
       * use a simple `slapos.recipe:wrapper` instead of `slapos.cookbook:egg_test`
       * fix the typo in repository name erp5-util-repository ->
         erp5.util-repository ( this mean we will have to fix the test suites in
         nexedi ERP5 )
       * document "what is this software" and a scenario of how this software
         can be used to develop slapos eggs.
       * switch to buildout-hash.cfg for easier template hash management.
      c91c4722
  2. 29 Mar, 2018 6 commits
  3. 28 Mar, 2018 2 commits
  4. 27 Mar, 2018 6 commits
  5. 26 Mar, 2018 2 commits
    • Kirill Smelkov's avatar
      golang: Hook-in pkg-config for Cgo support · df7db445
      Kirill Smelkov authored
      The most convenient way to discover CFLAGS/LDFLAGS when building Cgo bits is
      via pkg-config:
      
          https://golang.org/cmd/cgo/
      
      For this to work let's add pkg-config to be available there in gowork out of
      the box, and provide users with a way to specify which C packages they want to
      be there on gowork's $PKG_CONFIG_PATH, e.g. this way:
      
          [gowork]
          cpkgpath =
              ${sqlite3:location}/lib/pkgconfig
              ${zlib:location}/lib/pkgconfig
      
      In buildout sources cpkgpath is specified as multiline - not one line with ":"
      delimiters - with the idea that it should be easy to amend gowork.cpkgpath with "+="
      in different places.
      df7db445
    • Alain Takoudjou's avatar
      use slapos.core version 1.4.5 · 8d623f5f
      Alain Takoudjou authored
      8d623f5f
  6. 25 Mar, 2018 1 commit
  7. 22 Mar, 2018 1 commit
  8. 21 Mar, 2018 3 commits
  9. 20 Mar, 2018 2 commits
    • Boris Kocherov's avatar
      801110bb
    • Jérome Perrin's avatar
      tools: a simple git.mergetool for working with buildout.hash.cfg · 6dbd5cca
      Jérome Perrin authored
      Rewriting commit history with `git rebase -i` always caused some
      conflicts on md5sum of modified files. `update-hash` made all this
      easier, because we could just revert buildout.hash.cfg, re-run
      `update-hash` and commit the changes.
      
      This tool makes this scenario a bit more user friendly by automating the
      steps by running as a git mergetool.
      
      An interactive rebase session can be initiated by running this command
      from software/*/ directory:
      
      `git rebase -i --exec "$(pwd)/../../update-hash $(pwd)/buildout.hash.cfg" origin/master`
      
      and if conflict occur, run:
      
      `git mergetool --tool update-hash-mergetool && EDITOR=cat git rebase --continue`
      
      This way, rebase session can be almost non interactive (still have to
      run the above mergetool command) when conflicts are only on md5sum
      updates.
      
      /reviewed-on !273
      6dbd5cca
  10. 19 Mar, 2018 3 commits
  11. 16 Mar, 2018 9 commits
  12. 15 Mar, 2018 4 commits