setup: avoid setuptools 67 - it can't handle celery's broken pytz dependency

With setuptools 67 or later, launching Kallithea fails as:

  $ gearbox serve -c my.ini --reload
  15:56:54,111 ERROR [gearbox] Expected closing RIGHT_PARENTHESIS
      pytz (>dev)
           ~^

The `packaging` vendored in setuptools cannot handle the broken syntax
`Requires-Dist: pytz (>dev)` in
venv/lib/python3.11/site-packages/celery-5.0.5.dist-info/METADATA .

The old celery version currently used by Kallithea is wrong, and setuptools has
moved on after a reasonable grace period. We thus have to work around and avoid
latest setuptools.

See https://github.com/pypa/setuptools/issues/3889 .

Jenkinsfile

@@ -1,211 +1,211 b''
 def createvirtualenv = ''
 def activatevirtualenv = ''
 
 node {
     properties([[$class: 'BuildDiscarderProperty',
                   strategy: [$class: 'LogRotator',
                               artifactDaysToKeepStr: '',
                               artifactNumToKeepStr: '10',
                               daysToKeepStr: '',
                               numToKeepStr: '']]]);
     if (isUnix()) {
         createvirtualenv = 'rm -r $JENKINS_HOME/venv/$JOB_NAME || true && python3 -m venv $JENKINS_HOME/venv/$JOB_NAME'
         activatevirtualenv = '. $JENKINS_HOME/venv/$JOB_NAME/bin/activate'
     } else {
         createvirtualenv = 'rmdir /s /q %JENKINS_HOME%\\venv\\%JOB_NAME% || true && python3 -m venv %JENKINS_HOME%\\venv\\%JOB_NAME%'
         activatevirtualenv = 'call %JENKINS_HOME%\\venv\\%JOB_NAME%\\Scripts\\activate.bat'
     }
 
     stage('checkout') {
         checkout scm
         if (isUnix()) {
             sh 'hg --config extensions.purge= purge --all'
         } else {
             bat 'hg --config extensions.purge= purge --all'
         }
     }
     stage('virtual env') {
         def virtualenvscript = """$createvirtualenv
             $activatevirtualenv
             python -m pip install --upgrade pip
-            pip install --upgrade setuptools
+            pip install --upgrade "setuptools<67"
             pip install --upgrade pylint
             pip install --upgrade pytest-cov
             """
         if (isUnix()) {
             virtualenvscript += """
                 pip install --upgrade python-ldap
                 pip install --upgrade python-pam
                 """
             sh virtualenvscript
         } else {
             bat virtualenvscript
         }
     }
     stage('setup') {
         def virtualenvscript = """$activatevirtualenv
             pip install --upgrade -e . -r dev_requirements.txt
             python setup.py compile_catalog
             """
         if (isUnix()) {
             sh virtualenvscript
         } else {
             bat virtualenvscript
         }
         stash name: 'kallithea', useDefaultExcludes: false
     }
     stage('pylint') {
         sh script: """$activatevirtualenv
             pylint -j 0 --disable=C -f parseable kallithea > pylint.out
             """, returnStatus: true
         archiveArtifacts 'pylint.out'
         try {
             step([$class: 'WarningsPublisher', canComputeNew: false, canResolveRelativePaths: false, defaultEncoding: '', excludePattern: '', healthy: '', includePattern: '', messagesPattern: '', parserConfigurations: [[parserName: 'PyLint', pattern: 'pylint.out']], unHealthy: ''])
         } catch (java.lang.IllegalArgumentException exc) {
             echo "You need to install the 'Warnings Plug-in' to display the pylint report."
             currentBuild.result = 'UNSTABLE'
             echo "Caught: ${exc}"
         }
     }
 }
 
 def pytests = [:]
 pytests['sqlite'] = {
     node {
         ws {
             deleteDir()
             unstash name: 'kallithea'
             if (isUnix()) {
                 sh script: """$activatevirtualenv
                     py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_sqlite.xml --cov=kallithea
                     """, returnStatus: true
             } else {
                 bat script: """$activatevirtualenv
                     py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_sqlite.xml --cov=kallithea
                     """, returnStatus: true
             }
             sh 'sed --in-place "s/\\(classname=[\'\\"]\\)/\\1SQLITE./g" pytest_sqlite.xml'
             archiveArtifacts 'pytest_sqlite.xml'
             junit 'pytest_sqlite.xml'
             writeFile(file: '.coverage.sqlite', text: readFile('.coverage'))
             stash name: 'coverage.sqlite', includes: '.coverage.sqlite'
         }
     }
 }
 
 pytests['de'] = {
     node {
         if (isUnix()) {
             ws {
                 deleteDir()
                 unstash name: 'kallithea'
                 withEnv(['LANG=de_DE.UTF-8',
                     'LANGUAGE=de',
                     'LC_ADDRESS=de_DE.UTF-8',
                     'LC_IDENTIFICATION=de_DE.UTF-8',
                     'LC_MEASUREMENT=de_DE.UTF-8',
                     'LC_MONETARY=de_DE.UTF-8',
                     'LC_NAME=de_DE.UTF-8',
                     'LC_NUMERIC=de_DE.UTF-8',
                     'LC_PAPER=de_DE.UTF-8',
                     'LC_TELEPHONE=de_DE.UTF-8',
                     'LC_TIME=de_DE.UTF-8',
                 ]) {
                     sh script: """$activatevirtualenv
                         py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_de.xml --cov=kallithea
                         """, returnStatus: true
                 }
                 sh 'sed --in-place "s/\\(classname=[\'\\"]\\)/\\1DE./g" pytest_de.xml'
                 archiveArtifacts 'pytest_de.xml'
                 junit 'pytest_de.xml'
                 writeFile(file: '.coverage.de', text: readFile('.coverage'))
                 stash name: 'coverage.de', includes: '.coverage.de'
             }
         }
     }
 }
 pytests['mysql'] = {
     node {
         if (isUnix()) {
             ws {
                 deleteDir()
                 unstash name: 'kallithea'
                 sh """$activatevirtualenv
                     pip install --upgrade MySQL-python
                     """
                 withEnv(['TEST_DB=mysql://kallithea:kallithea@jenkins_mysql/kallithea_test?charset=utf8']) {
                     if (isUnix()) {
                         sh script: """$activatevirtualenv
                             py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_mysql.xml --cov=kallithea
                             """, returnStatus: true
                     } else {
                         bat script: """$activatevirtualenv
                             py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_mysql.xml --cov=kallithea
                             """, returnStatus: true
                     }
                 }
                 sh 'sed --in-place "s/\\(classname=[\'\\"]\\)/\\1MYSQL./g" pytest_mysql.xml'
                 archiveArtifacts 'pytest_mysql.xml'
                 junit 'pytest_mysql.xml'
                 writeFile(file: '.coverage.mysql', text: readFile('.coverage'))
                 stash name: 'coverage.mysql', includes: '.coverage.mysql'
             }
         }
     }
 }
 pytests['postgresql'] = {
     node {
         if (isUnix()) {
             ws {
                 deleteDir()
                 unstash name: 'kallithea'
                 sh """$activatevirtualenv
                     pip install --upgrade psycopg2
                     """
                 withEnv(['TEST_DB=postgresql://kallithea:kallithea@jenkins_postgresql/kallithea_test']) {
                     if (isUnix()) {
                         sh script: """$activatevirtualenv
                             py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_postgresql.xml --cov=kallithea
                             """, returnStatus: true
                     } else {
                         bat script: """$activatevirtualenv
                             py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_postgresql.xml --cov=kallithea
                             """, returnStatus: true
                     }
                 }
                 sh 'sed --in-place "s/\\(classname=[\'\\"]\\)/\\1POSTGRES./g" pytest_postgresql.xml'
                 archiveArtifacts 'pytest_postgresql.xml'
                 junit 'pytest_postgresql.xml'
                 writeFile(file: '.coverage.postgresql', text: readFile('.coverage'))
                 stash name: 'coverage.postgresql', includes: '.coverage.postgresql'
             }
         }
     }
 }
 stage('Tests') {
     parallel pytests
     node {
         unstash 'coverage.sqlite'
         unstash 'coverage.de'
         unstash 'coverage.mysql'
         unstash 'coverage.postgresql'
         if (isUnix()) {
             sh script: """$activatevirtualenv
                 coverage combine .coverage.sqlite .coverage.de .coverage.mysql .coverage.postgresql
                 coverage xml
                 """, returnStatus: true
         } else {
             bat script: """$activatevirtualenv
                 coverage combine .coverage.sqlite .coverage.de .coverage.mysql .coverage.postgresql
                 coverage xml
                 """, returnStatus: true
         }
         try {
             step([$class: 'CoberturaPublisher', autoUpdateHealth: false, autoUpdateStability: false, coberturaReportFile: 'coverage.xml', failNoReports: false, failUnhealthy: false, failUnstable: false, maxNumberOfBuilds: 0, onlyStable: false, zoomCoverageChart: false])
         } catch (java.lang.IllegalArgumentException exc) {
             echo "You need to install the pipeline compatible 'CoberturaPublisher Plug-in' to display the coverage report."
             currentBuild.result = 'UNSTABLE'
             echo "Caught: ${exc}"
         }
     }
 }

docs/contributing.rst

@@ -1,397 +1,397 b''
 .. _contributing:
 
 =========================
 Contributing to Kallithea
 =========================
 
 Kallithea is developed and maintained by its users. Please join us and scratch
 your own itch.
 
 
 Infrastructure
 --------------
 
 The main repository is hosted on Our Own Kallithea (aka OOK) at
 https://kallithea-scm.org/repos/kallithea/, our self-hosted instance
 of Kallithea.
 
 Please use the `mailing list`_ to send patches or report issues.
 
 We use Weblate_ to translate the user interface messages into languages other
 than English. Join our project on `Hosted Weblate`_ to help us.
 To register, you can use your Bitbucket or GitHub account. See :ref:`translations`
 for more details.
 
 
 Getting started
 ---------------
 
 To get started with Kallithea development run the following commands in your
 bash shell::
 
         hg clone https://kallithea-scm.org/repos/kallithea
         cd kallithea
         python3 -m venv venv
         . venv/bin/activate
-        pip install --upgrade pip setuptools
+        pip install --upgrade pip "setuptools<67"
         pip install --upgrade -e . -r dev_requirements.txt python-ldap python-pam
         kallithea-cli config-create my.ini
         kallithea-cli db-create -c my.ini --user=user --email=[e-mail] --password=password --repos=/tmp
         kallithea-cli front-end-build
         gearbox serve -c my.ini --reload &
         firefox http://127.0.0.1:5000/
 
 
 Contribution flow
 -----------------
 
 Starting from an existing Kallithea clone, make sure it is up to date with the
 latest upstream changes::
 
         hg pull
         hg update
 
 Review the :ref:`contributing-guidelines` and :ref:`coding-guidelines`.
 
 If you are new to Mercurial, refer to Mercurial `Quick Start`_ and `Beginners
 Guide`_ on the Mercurial wiki.
 
 Now, make some changes and test them (see :ref:`contributing-tests`). Don't
 forget to add new tests to cover new functionality or bug fixes.
 
 For documentation changes, run ``make html`` from the ``docs`` directory to
 generate the HTML result, then review them in your browser.
 
 Before submitting any changes, run the cleanup script::
 
         ./scripts/run-all-cleanup
 
 When you are completely ready, you can send your changes to the community for
 review and inclusion, via the mailing list (via ``hg email``).
 
 .. _contributing-tests:
 
 
 Internal dependencies
 ---------------------
 
 We try to keep the code base clean and modular and avoid circular dependencies.
 Code should only invoke code in layers below itself.
 
 Imports should import whole modules ``from`` their parent module, perhaps
 ``as`` a shortened name. Avoid imports ``from`` modules.
 
 To avoid cycles and partially initialized modules, ``__init__.py`` should *not*
 contain any non-trivial imports. The top level of a module should *not* be a
 facade for the module functionality.
 
 Common code for a module is often in ``base.py``.
 
 The important part of the dependency graph is approximately linear. In the
 following list, modules may only depend on modules below them:
 
 ``tests``
   Just get the job done - anything goes.
 
 ``bin/`` & ``config/`` & ``alembic/``
   The main entry points, defined in ``setup.py``. Note: The TurboGears template
   use ``config`` for the high WSGI application - this is not for low level
   configuration.
 
 ``controllers/``
   The top level web application, with TurboGears using the ``root`` controller
   as entry point, and ``routing`` dispatching to other controllers.
 
 ``templates/**.html``
   The "view", rendering to HTML. Invoked by controllers which can pass them
   anything from lower layers - especially ``helpers`` available as ``h`` will
   cut through all layers, and ``c`` gives access to global variables.
 
 ``lib/helpers.py``
   High level helpers, exposing everything to templates as ``h``. It depends on
   everything and has a huge dependency chain, so it should not be used for
   anything else. TODO.
 
 ``controllers/base.py``
   The base class of controllers, with lots of model knowledge.
 
 ``lib/auth.py``
   All things related to authentication. TODO.
 
 ``lib/utils.py``
   High level utils with lots of model knowledge. TODO.
 
 ``lib/hooks.py``
   Hooks into "everything" to give centralized logging to database, cache
   invalidation, and extension handling. TODO.
 
 ``model/``
   Convenience business logic wrappers around database models.
 
 ``model/db.py``
   Defines the database schema and provides some additional logic.
 
 ``model/scm.py``
   All things related to anything. TODO.
 
 SQLAlchemy
   Database session and transaction in thread-local variables.
 
 ``lib/utils2.py``
   Low level utils specific to Kallithea.
 
 ``lib/webutils.py``
   Low level generic utils with awareness of the TurboGears environment.
 
 TurboGears
   Request, response and state like i18n gettext in thread-local variables.
   External dependency with global state - usage should be minimized.
 
 ``lib/vcs/``
   Previously an independent library. No awareness of web, database, or state.
 
 ``lib/*``
   Various "pure" functionality not depending on anything else.
 
 ``__init__``
   Very basic Kallithea constants - some of them are set very early based on ``.ini``.
 
 This is not exactly how it is right now, but we aim for something like that.
 Especially the areas marked as TODO have some problems that need untangling.
 
 
 Running tests
 -------------
 
 After finishing your changes make sure all tests pass cleanly. Run the testsuite
 by invoking ``py.test`` from the project root::
 
     py.test
 
 Note that on unix systems, the temporary directory (``/tmp`` or where
 ``$TMPDIR`` points) must allow executable files; Git hooks must be executable,
 and the test suite creates repositories in the temporary directory. Linux
 systems with /tmp mounted noexec will thus fail.
 
 Tests can be run on PostgreSQL like::
 
     sudo -u postgres createuser 'kallithea-test' --pwprompt  # password password
     sudo -u postgres createdb 'kallithea-test' --owner 'kallithea-test'
     REUSE_TEST_DB='postgresql://kallithea-test:password@localhost/kallithea-test' py.test
 
 Tests can be run on MariaDB/MySQL like::
 
     echo "GRANT ALL PRIVILEGES ON \`kallithea-test\`.* TO 'kallithea-test'@'localhost' IDENTIFIED BY 'password'" | sudo -u mysql mysql
     TEST_DB='mysql://kallithea-test:password@localhost/kallithea-test?charset=utf8mb4' py.test
 
 You can also use ``tox`` to run the tests with all supported Python versions.
 
 When running tests, Kallithea generates a `test.ini` based on template values
 in `kallithea/tests/conftest.py` and populates the SQLite database specified
 there.
 
 It is possible to avoid recreating the full test database on each invocation of
 the tests, thus eliminating the initial delay. To achieve this, run the tests as::
 
     gearbox serve -c /tmp/kallithea-test-XXX/test.ini --pid-file=test.pid --daemon
     KALLITHEA_WHOOSH_TEST_DISABLE=1 KALLITHEA_NO_TMP_PATH=1 py.test
     kill -9 $(cat test.pid)
 
 In these commands, the following variables are used::
 
     KALLITHEA_WHOOSH_TEST_DISABLE=1 - skip whoosh index building and tests
     KALLITHEA_NO_TMP_PATH=1 - disable new temp path for tests, used mostly for testing_vcs_operations
 
 You can run individual tests by specifying their path as argument to py.test.
 py.test also has many more options, see `py.test -h`. Some useful options
 are::
 
     -k EXPRESSION         only run tests which match the given substring
                           expression. An expression is a python evaluable
                           expression where all names are substring-matched
                           against test names and their parent classes. Example:
     -x, --exitfirst       exit instantly on first error or failed test.
     --lf                  rerun only the tests that failed at the last run (or
                           all if none failed)
     --ff                  run all tests but run the last failures first. This
                           may re-order tests and thus lead to repeated fixture
                           setup/teardown
     --pdb                 start the interactive Python debugger on errors.
     -s, --capture=no      don't capture stdout (any stdout output will be
                           printed immediately)
 
 Performance tests
 ^^^^^^^^^^^^^^^^^
 
 A number of performance tests are present in the test suite, but they are
 not run in a standard test run. These tests are useful to
 evaluate the impact of certain code changes with respect to performance.
 
 To run these tests::
 
     env TEST_PERFORMANCE=1 py.test kallithea/tests/performance
 
 To analyze performance, you could install pytest-profiling_, which enables the
 --profile and --profile-svg options to py.test.
 
 .. _pytest-profiling: https://github.com/manahl/pytest-plugins/tree/master/pytest-profiling
 
 .. _contributing-guidelines:
 
 
 Contribution guidelines
 -----------------------
 
 Kallithea is GPLv3 and we assume all contributions are made by the
 committer/contributor and under GPLv3 unless explicitly stated. We do care a
 lot about preservation of copyright and license information for existing code
 that is brought into the project.
 
 Contributions will be accepted in most formats -- such as commits hosted on your
 own Kallithea instance, or patches sent by email to the `kallithea-general`_
 mailing list.
 
 Make sure to test your changes both manually and with the automatic tests
 before posting.
 
 We care about quality and review and keeping a clean repository history. We
 might give feedback that requests polishing contributions until they are
 "perfect". We might also rebase and collapse and make minor adjustments to your
 changes when we apply them.
 
 We try to make sure we have consensus on the direction the project is taking.
 Everything non-sensitive should be discussed in public -- preferably on the
 mailing list.  We aim at having all non-trivial changes reviewed by at least
 one other core developer before pushing. Obvious non-controversial changes will
 be handled more casually.
 
 There is a main development branch ("default") which is generally stable so that
 it can be (and is) used in production. There is also a "stable" branch that is
 almost exclusively reserved for bug fixes or trivial changes. Experimental
 changes should live elsewhere (for example in a pull request) until they are
 ready.
 
 .. _coding-guidelines:
 
 
 Coding guidelines
 -----------------
 
 We don't have a formal coding/formatting standard. We are currently using a mix
 of Mercurial's (https://www.mercurial-scm.org/wiki/CodingStyle), pep8, and
 consistency with existing code. Run ``scripts/run-all-cleanup`` before
 committing to ensure some basic code formatting consistency.
 
 We support Python 3.6 and later.
 
 We try to support the most common modern web browsers. IE9 is still supported
 to the extent it is feasible, IE8 is not.
 
 We primarily support Linux and OS X on the server side but Windows should also work.
 
 HTML templates should use 2 spaces for indentation ... but be pragmatic. We
 should use templates cleverly and avoid duplication. We should use reasonable
 semantic markup with element classes and IDs that can be used for styling and testing.
 We should only use inline styles in places where it really is semantic (such as
 ``display: none``).
 
 JavaScript must use ``;`` between/after statements. Indentation 4 spaces. Inline
 multiline functions should be indented two levels -- one for the ``()`` and one for
 ``{}``.
 Variables holding jQuery objects should be named with a leading ``$``.
 
 Commit messages should have a leading short line summarizing the changes. For
 bug fixes, put ``(Issue #123)`` at the end of this line.
 
 Use American English grammar and spelling overall. Use `English title case`_ for
 page titles, button labels, headers, and 'labels' for fields in forms.
 
 .. _English title case: https://en.wikipedia.org/wiki/Capitalization#Title_case
 
 Template helpers (that is, everything in ``kallithea.lib.helpers``)
 should only be referenced from templates. If you need to call a
 helper from the Python code, consider moving the function somewhere
 else (e.g. to the model).
 
 Notes on the SQLAlchemy session
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Each HTTP request runs inside an independent SQLAlchemy session (as well
 as in an independent database transaction). ``Session`` is the session manager
 and factory. ``Session()`` will create a new session on-demand or return the
 current session for the active thread. Many database operations are methods on
 such session instances. The session will generally be removed by
 TurboGears automatically.
 
 Database model objects
 (almost) always belong to a particular SQLAlchemy session, which means
 that SQLAlchemy will ensure that they're kept in sync with the database
 (but also means that they cannot be shared across requests).
 
 Objects can be added to the session using ``Session().add``, but this is
 rarely needed:
 
 * When creating a database object by calling the constructor directly,
   it must explicitly be added to the session.
 
 * When creating an object using a factory function (like
   ``create_repo``), the returned object has already (by convention)
   been added to the session, and should not be added again.
 
 * When getting an object from the session (via ``Session().query`` or
   any of the utility functions that look up objects in the database),
   it's already part of the session, and should not be added again.
   SQLAlchemy monitors attribute modifications automatically for all
   objects it knows about and syncs them to the database.
 
 SQLAlchemy also flushes changes to the database automatically; manually
 calling ``Session().flush`` is usually only necessary when the Python
 code needs the database to assign an "auto-increment" primary key ID to
 a freshly created model object (before flushing, the ID attribute will
 be ``None``).
 
 Debugging
 ^^^^^^^^^
 
 A good way to trace what Kallithea is doing is to keep an eye on the output on
 stdout/stderr of the server process. Perhaps change ``my.ini`` to log at
 ``DEBUG`` or ``INFO`` level, especially ``[logger_kallithea]``, but perhaps
 also other loggers. It is often easier to add additional ``log`` or ``print``
 statements than to use a Python debugger.
 
 Sometimes it is simpler to disable ``errorpage.enabled`` and perhaps also
 ``trace_errors.enable`` to expose raw errors instead of adding extra
 processing. Enabling ``debug`` can be helpful for showing and exploring
 tracebacks in the browser, but is also insecure and will add extra processing.
 
 TurboGears2 DebugBar
 ^^^^^^^^^^^^^^^^^^^^
 
 It is possible to enable the TurboGears2-provided DebugBar_, a toolbar overlayed
 over the Kallithea web interface, allowing you to see:
 
 * timing information of the current request, including profiling information
 * request data, including GET data, POST data, cookies, headers and environment
   variables
 * a list of executed database queries, including timing and result values
 
 DebugBar is only activated when ``debug = true`` is set in the configuration
 file. This is important, because the DebugBar toolbar will be visible for all
 users, and allow them to see information they should not be allowed to see. Like
 is anyway the case for ``debug = true``, do not use this in production!
 
 To enable DebugBar, install ``tgext.debugbar`` and ``kajiki`` (typically via
 ``pip``) and restart Kallithea (in debug mode).
 
 
 Thank you for your contribution!
 --------------------------------
 
 
 .. _Weblate: http://weblate.org/
 .. _mailing list: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
 .. _kallithea-general: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
 .. _Hosted Weblate: https://hosted.weblate.org/projects/kallithea/kallithea/
 .. _DebugBar: https://github.com/TurboGears/tgext.debugbar
 .. _Quick Start: https://www.mercurial-scm.org/wiki/QuickStart
 .. _Beginners Guide: https://www.mercurial-scm.org/wiki/BeginnersGuides

docs/installation.rst

@@ -1,144 +1,144 b''
 .. _installation:
 
 ==========================
 Installation on Unix/Linux
 ==========================
 
 The following describes three different ways of installing Kallithea:
 
 - :ref:`installation-source`: The simplest way to keep the installation
   up-to-date and track any local customizations is to run directly from
   source in a Kallithea repository clone, preferably inside a virtualenv
   virtual Python environment.
 
 - :ref:`installation-virtualenv`: If you prefer to only use released versions
   of Kallithea, the recommended method is to install Kallithea in a virtual
   Python environment using `virtualenv`. The advantages of this method over
   direct installation is that Kallithea and its dependencies are completely
   contained inside the virtualenv (which also means you can have multiple
   installations side by side or remove it entirely by just removing the
   virtualenv directory) and does not require root privileges.
 
 - Kallithea can also be installed with plain pip - globally or with ``--user``
   or similar. The package will be installed in the same location as all other
   Python packages you have ever installed. As a result, removing it is not as
   straightforward as with a virtualenv, as you'd have to remove its
   dependencies manually and make sure that they are not needed by other
   packages. We recommend using virtualenv.
 
 Regardless of the installation method you may need to make sure you have
 appropriate development packages installed, as installation of some of the
 Kallithea dependencies requires a working C compiler and libffi library
 headers. Depending on your configuration, you may also need to install
 Git and development packages for the database of your choice.
 
 For Debian and Ubuntu, the following command will ensure that a reasonable
 set of dependencies is installed::
 
     sudo apt-get install build-essential git libffi-dev python3-dev
 
 For Fedora and RHEL-derivatives, the following command will ensure that a
 reasonable set of dependencies is installed::
 
     sudo yum install gcc git libffi-devel python3-devel
 
 .. _installation-source:
 
 
 Installation from repository source
 -----------------------------------
 
 To install Kallithea in a virtualenv using the stable branch of the development
 repository, use the following commands in your bash shell::
 
         hg clone https://kallithea-scm.org/repos/kallithea -u stable
         cd kallithea
         python3 -m venv venv
         . venv/bin/activate
-        pip install --upgrade pip setuptools
+        pip install --upgrade pip "setuptools<67"
         pip install --upgrade -e .
         python3 setup.py compile_catalog   # for translation of the UI
 
 .. note::
    This will install all Python dependencies into the virtualenv. Kallithea
    itself will however only be installed as a pointer to the source location.
    The source clone must thus be kept in the same location, and it shouldn't be
    updated to other revisions unless you want to upgrade. Edits in the source
    tree will have immediate impact (possibly after a restart of the service).
 
 You can now proceed to :ref:`prepare-front-end-files`.
 
 .. _installation-virtualenv:
 
 
 Installing a released version in a virtualenv
 ---------------------------------------------
 
 It is highly recommended to use a separate virtualenv for installing Kallithea.
 This way, all libraries required by Kallithea will be installed separately from your
 main Python installation and other applications and things will be less
 problematic when upgrading the system or Kallithea.
 An additional benefit of virtualenv is that it doesn't require root privileges.
 
 - Don't install as root - install as a dedicated user like ``kallithea``.
   If necessary, create the top directory for the virtualenv (like
   ``/srv/kallithea/venv``) as root and assign ownership to the user.
 
   Make a parent folder for the virtualenv (and perhaps also Kallithea
   configuration and data files) such as ``/srv/kallithea``. Create the
   directory as root if necessary and grant ownership to the ``kallithea`` user.
 
 - Create a new virtual environment, for example in ``/srv/kallithea/venv``,
   specifying the right Python binary::
 
     python3 -m venv /srv/kallithea/venv
 
 - Activate the virtualenv in your current shell session and make sure the
   basic requirements are up-to-date by running the following commands in your
   bash shell::
 
     . /srv/kallithea/venv/bin/activate
-    pip install --upgrade pip setuptools
+    pip install --upgrade pip "setuptools<67"
 
 .. note:: You can't use UNIX ``sudo`` to source the ``activate`` script; it
    will "activate" a shell that terminates immediately.
 
 - Install Kallithea in the activated virtualenv::
 
     pip install --upgrade kallithea
 
 .. note:: Some dependencies are optional. If you need them, install them in
    the virtualenv too::
 
      pip install --upgrade kallithea python-ldap python-pam psycopg2
 
    This might require installation of development packages using your
    distribution's package manager.
 
    Alternatively, download a .tar.gz from http://pypi.python.org/pypi/Kallithea,
    extract it and install from source by running::
 
      pip install --upgrade .
 
 - This will install Kallithea together with all other required
   Python libraries into the activated virtualenv.
 
 You can now proceed to :ref:`prepare-front-end-files`.
 
 .. _prepare-front-end-files:
 
 
 Prepare front-end files
 -----------------------
 
 Finally, the front-end files with CSS and JavaScript must be prepared. This
 depends on having some commands available in the shell search path: ``npm``
 version 6 or later, and ``node.js`` (version 12 or later) available as
 ``node``. The installation method for these dependencies varies between
 operating systems and distributions.
 
 Prepare the front-end by running::
 
     kallithea-cli front-end-build
 
 You can now proceed to :ref:`setup`.

docs/installation_win.rst

@@ -1,193 +1,193 b''
 .. _installation_win:
 
 .. warning:: This section is outdated and needs updating for Python 3.
 
 ====================================================
 Installation on Windows (7/Server 2008 R2 and newer)
 ====================================================
 
 
 First time install
 ------------------
 
 Target OS: Windows 7 and newer or Windows Server 2008 R2 and newer
 
 Tested on Windows 8.1, Windows Server 2008 R2 and Windows Server 2012
 
 To install on an older version of Windows, see `<installation_win_old.html>`_
 
 Step 1 -- Install Python
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 Install Python 3. Latest version is recommended. If you need another version, they can run side by side.
 
 - Download Python 3 from http://www.python.org/download/
 - Choose and click on the version
 - Click on "Windows X86-64 Installer" for x64 or "Windows x86 MSI installer" for Win32.
 - Disable UAC or run the installer with admin privileges. If you chose to disable UAC, do not forget to reboot afterwards.
 
 While writing this guide, the latest version was v3.8.1.
 Remember the specific major and minor versions installed, because they will
 be needed in the next step. In this case, it is "3.8".
 
 Step 2 -- Python BIN
 ^^^^^^^^^^^^^^^^^^^^
 
 Add Python BIN folder to the path. This can be done manually (editing
 "PATH" environment variable) or by using Windows Support Tools that
 come pre-installed in Windows Vista/7 and later.
 
 Open a CMD and type::
 
   SETX PATH "%PATH%;[your-python-path]" /M
 
 Please substitute [your-python-path] with your Python installation
 path. Typically this is ``C:\\Python38``.
 
 Step 3 -- Install pywin32 extensions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Download pywin32 from:
 http://sourceforge.net/projects/pywin32/files/
 
 - Click on "pywin32" folder
 - Click on the first folder (in this case, Build 219, maybe newer when you try)
 - Choose the file ending with ".amd64-py3.x.exe" (".win32-py3.x.exe"
   for Win32) where x is the minor version of Python you installed.
   When writing this guide, the file was:
   http://sourceforge.net/projects/pywin32/files/pywin32/Build%20219/pywin32-219.win-amd64-py3.8.exe/download
   (x64)
   http://sourceforge.net/projects/pywin32/files/pywin32/Build%20219/pywin32-219.win32-py3.8.exe/download
   (Win32)
 
 Step 5 -- Kallithea folder structure
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Create a Kallithea folder structure.
 
 This is only an example to install Kallithea. Of course, you can
 change it. However, this guide will follow the proposed structure, so
 please later adapt the paths if you change them. Folders without
 spaces are recommended.
 
 Create the following folder structure::
 
   C:\Kallithea
   C:\Kallithea\Bin
   C:\Kallithea\Env
   C:\Kallithea\Repos
 
 Step 6 -- Install virtualenv
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. note::
    A python virtual environment will allow for isolation between the Python packages of your system and those used for Kallithea.
    It is strongly recommended to use it to ensure that Kallithea does not change a dependency that other software uses or vice versa.
 
 To create a virtual environment, run::
 
   python3 -m venv C:\Kallithea\Env
 
 Step 7 -- Install Kallithea
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In order to install Kallithea, you need to be able to run "pip install kallithea". It will use pip to install the Kallithea Python package and its dependencies.
 Some Python packages use managed code and need to be compiled.
 This can be done on Linux without any special steps. On Windows, you will need to install Microsoft Visual C++ compiler for Python 3.8.
 
 Download and install "Microsoft Visual C++ Compiler for Python 3.8" from http://aka.ms/vcpython27
 
 .. note::
   You can also install the dependencies using already compiled Windows binaries packages. A good source of compiled Python packages is http://www.lfd.uci.edu/~gohlke/pythonlibs/. However, not all of the necessary packages for Kallithea are on this site and some are hard to find, so we will stick with using the compiler.
 
 In a command prompt type (adapting paths if necessary)::
 
   cd C:\Kallithea\Env\Scripts
   activate
-  pip install --upgrade pip setuptools
+  pip install --upgrade pip "setuptools<67"
 
 The prompt will change into "(Env) C:\\Kallithea\\Env\\Scripts" or similar
 (depending of your folder structure). Then type::
 
   pip install kallithea
 
 .. note:: This will take some time. Please wait patiently until it is fully
           complete. Some warnings will appear. Don't worry, they are
           normal.
 
 Step 8 -- Install Git (optional)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Mercurial being a python package, was installed automatically when doing ``pip install kallithea``.
 
 You need to install Git manually if you want Kallithea to be able to host Git repositories.
 See http://git-scm.com/book/en/v2/Getting-Started-Installing-Git#Installing-on-Windows for instructions.
 The location of the Git binaries (like ``c:\path\to\git\bin``) must be
 added to the ``PATH`` environment variable so ``git.exe`` and other tools like
 ``gzip.exe`` are available.
 
 Step 9 -- Configuring Kallithea
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Steps taken from `<setup.html>`_
 
 You have to use the same command prompt as in Step 7, so if you closed
 it, reopen it following the same commands (including the "activate"
 one). When ready, type::
 
   cd C:\Kallithea\Bin
   kallithea-cli config-create my.ini
 
 Then you must edit my.ini to fit your needs (IP address, IP
 port, mail settings, database, etc.). `NotePad++`__ or a similar text
 editor is recommended to properly handle the newline character
 differences between Unix and Windows.
 
 __ http://notepad-plus-plus.org/
 
 For the sake of simplicity, run it with the default settings. After your edits (if any) in the previous command prompt, type::
 
   kallithea-cli db-create -c my.ini
 
 .. warning:: This time a *new* database will be installed. You must
              follow a different process to later :ref:`upgrade <upgrade>`
              to a newer Kallithea version.
 
 The script will ask you for confirmation about creating a new database, answer yes (y)
 
 The script will ask you for the repository path, answer C:\\Kallithea\\Repos (or similar).
 
 The script will ask you for the admin username and password, answer "admin" + "123456" (or whatever you want)
 
 The script will ask you for admin mail, answer "[e-mail]" (or whatever you want).
 
 If you make a mistake and the script doesn't end, don't worry: start it again.
 
 If you decided not to install Git, you will get errors about it that you can ignore.
 
 Step 10 -- Running Kallithea
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In the previous command prompt, being in the C:\\Kallithea\\Bin folder, type::
 
   gearbox serve -c my.ini
 
 Open your web server, and go to http://127.0.0.1:5000
 
 It works!! :-)
 
 Remark:
 If it does not work the first time, Ctrl-C the CMD process and start it again. Don't forget the "http://" in Internet Explorer.
 
 What this guide does not cover:
 
 - Installing Celery
 - Running Kallithea as a Windows Service. You can investigate here:
 
   - http://pypi.python.org/pypi/wsgisvc
   - http://ryrobes.com/python/running-python-scripts-as-a-windows-service/
   - http://wiki.pylonshq.com/display/pylonscookbook/How+to+run+Pylons+as+a+Windows+service
 
 - Using Apache. You can investigate here:
 
   - https://groups.google.com/group/rhodecode/msg/c433074e813ffdc4

docs/installation_win_old.rst

@@ -1,250 +1,250 b''
 .. _installation_win_old:
 
 .. warning:: This section is outdated and needs updating for Python 3.
 
 ==========================================================
 Installation on Windows (XP/Vista/Server 2003/Server 2008)
 ==========================================================
 
 
 First-time install
 ------------------
 
 Target OS: Windows XP SP3 32-bit English (Clean installation)
 + All Windows Updates until 24-may-2012
 
 .. note::
 
    This installation is for 32-bit systems, for 64-bit Windows you might need
    to download proper 64-bit versions of the different packages (Windows Installer, Win32py extensions)
    plus some extra tweaks.
    These extra steps haven been marked as "64-bit".
    Tested on Windows Server 2008 R2 SP1, 9-feb-2013.
    If you run into any 64-bit related problems, please check these pages:
 
    - http://blog.victorjabur.com/2011/06/05/compiling-python-2-7-modules-on-windows-32-and-64-using-msvc-2008-express/
    - http://bugs.python.org/issue7511
 
 Step 1 -- Install Visual Studio 2008 Express
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Optional: You can also install MinGW, but VS2008 installation is easier.
 
 Download "Visual C++ 2008 Express Edition with SP1" from:
 http://download.microsoft.com/download/E/8/E/E8EEB394-7F42-4963-A2D8-29559B738298/VS2008ExpressWithSP1ENUX1504728.iso
 (if not found or relocated, google for "visual studio 2008 express" for updated link. This link was taken from http://stackoverflow.com/questions/15318560/visual-c-2008-express-download-link-dead)
 
 You can also download full ISO file for offline installation, just
 choose "All -- Offline Install ISO image file" in the previous page and
 choose "Visual C++ 2008 Express" when installing.
 
 .. note::
 
    Using other versions of Visual Studio will lead to random crashes.
    You must use Visual Studio 2008!"
 
 .. note::
 
    Silverlight Runtime and SQL Server 2008 Express Edition are not
    required, you can uncheck them
 
 .. note::
 
    64-bit: You also need to install the Microsoft Windows SDK for .NET 3.5 SP1 (.NET 4.0 won't work).
    Download from: http://www.microsoft.com/en-us/download/details.aspx?id=3138
 
 .. note::
 
    64-bit: You also need to copy and rename a .bat file to make the Visual C++ compiler work.
    I am not sure why this is not necessary for 32-bit.
    Copy C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\vcvars64.bat to C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat
 
 Step 2 -- Install Python
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 Install Python 3.8.x from:
 http://www.python.org/download/
 
 Remember the specific major and minor version installed, because it will
 be needed in the next step. In this case, it is "3.8".
 
 .. note::
 
    64-bit: Just download and install the 64-bit version of python.
 
 Step 3 -- Install Win32py extensions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Download pywin32 from:
 http://sourceforge.net/projects/pywin32/files/
 
 - Click on "pywin32" folder
 - Click on the first folder (in this case, Build 218, maybe newer when you try)
 - Choose the file ending with ".win32-py3.x.exe" -> x being the minor
   version of Python you installed (in this case, 7)
   When writing this guide, the file was:
   http://sourceforge.net/projects/pywin32/files/pywin32/Build%20218/pywin32-218.win-amd64-py3.8.exe/download
 
   .. note::
 
      64-bit: Download and install the 64-bit version.
      At the time of writing you can find this at:
      http://sourceforge.net/projects/pywin32/files/pywin32/Build%20218/pywin32-218.win-amd64-py3.8.exe/download
 
 Step 4 -- Python BIN
 ^^^^^^^^^^^^^^^^^^^^
 
 Add Python BIN folder to the path
 
 You have to add the Python folder to the path, you can do it manually
 (editing "PATH" environment variable) or using Windows Support Tools
 that came preinstalled in Vista/7 and can be installed in Windows XP.
 
 - Using support tools on WINDOWS XP:
   If you use Windows XP you can install them using Windows XP CD and
   navigating to \SUPPORT\TOOLS. There, execute Setup.EXE (not MSI).
   Afterwards, open a CMD and type::
 
     SETX PATH "%PATH%;[your-python-path]" -M
 
   Close CMD (the path variable will be updated then)
 
 - Using support tools on WINDOWS Vista/7:
 
   Open a CMD and type::
 
     SETX PATH "%PATH%;[your-python-path]" /M
 
   Please substitute [your-python-path] with your Python installation path.
   Typically: C:\\Python38
 
 Step 5 -- Kallithea folder structure
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Create a Kallithea folder structure
 
 This is only a example to install Kallithea, you can of course change
 it. However, this guide will follow the proposed structure, so please
 later adapt the paths if you change them. My recommendation is to use
 folders with NO SPACES. But you can try if you are brave...
 
 Create the following folder structure::
 
   C:\Kallithea
   C:\Kallithea\Bin
   C:\Kallithea\Env
   C:\Kallithea\Repos
 
 Step 6 -- Install virtualenv
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Create a virtual Python environment in C:\\Kallithea\\Env (or similar). To
 do so, open a CMD (Python Path should be included in Step3), and write::
 
   python3 -m venv C:\Kallithea\Env
 
 Step 7 -- Install Kallithea
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Finally, install Kallithea
 
 Close previously opened command prompt/s, and open a Visual Studio 2008
 Command Prompt (**IMPORTANT!!**). To do so, go to Start Menu, and then open
 "Microsoft Visual C++ 2008 Express Edition" -> "Visual Studio Tools" ->
 "Visual Studio 2008 Command Prompt"
 
 .. note::
 
    64-bit: For 64-bit you need to modify the shortcut that is used to start the
    Visual Studio 2008 Command Prompt. Use right-mouse click to open properties.
 
 Change commandline from::
 
 %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"" x86
 
 to::
 
 %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"" amd64
 
 In that CMD (loaded with VS2008 PATHs) type::
 
   cd C:\Kallithea\Env\Scripts (or similar)
   activate
-  pip install --upgrade pip setuptools
+  pip install --upgrade pip "setuptools<67"
 
 The prompt will change into "(Env) C:\\Kallithea\\Env\\Scripts" or similar
 (depending of your folder structure). Then type::
 
  pip install kallithea
 
 (long step, please wait until fully complete)
 
 Some warnings will appear, don't worry as they are normal.
 
 Step 8 -- Configuring Kallithea
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 steps taken from http://packages.python.org/Kallithea/setup.html
 
 You have to use the same Visual Studio 2008 command prompt as Step7, so
 if you closed it reopen it following the same commands (including the
 "activate" one). When ready, just type::
 
   cd C:\Kallithea\Bin
   kallithea-cli config-create my.ini
 
 Then, you must edit my.ini to fit your needs (network address and
 port, mail settings, database, whatever). I recommend using NotePad++
 (free) or similar text editor, as it handles well the EndOfLine
 character differences between Unix and Windows
 (http://notepad-plus-plus.org/)
 
 For the sake of simplicity lets run it with the default settings. After
 your edits (if any), in the previous Command Prompt, type::
 
   kallithea-cli db-create -c my.ini
 
 .. warning:: This time a *new* database will be installed. You must
              follow a different process to later :ref:`upgrade <upgrade>`
              to a newer Kallithea version.
 
 The script will ask you for confirmation about creating a NEW database,
 answer yes (y)
 The script will ask you for repository path, answer C:\\Kallithea\\Repos
 (or similar)
 The script will ask you for admin username and password, answer "admin"
 + "123456" (or whatever you want)
 The script will ask you for admin mail, answer "[e-mail]" (or
 whatever you want)
 
 If you make some mistake and the script does not end, don't worry, start
 it again.
 
 Step 9 -- Running Kallithea
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In the previous command prompt, being in the C:\\Kallithea\\Bin folder,
 just type::
 
  gearbox serve -c my.ini
 
 Open yout web server, and go to http://127.0.0.1:5000
 
 It works!! :-)
 
 Remark:
 If it does not work first time, just Ctrl-C the CMD process and start it
 again. Don't forget the "http://" in Internet Explorer
 
 What this Guide does not cover:
 
 - Installing Celery
 - Running Kallithea as Windows Service. You can investigate here:
 
   - http://pypi.python.org/pypi/wsgisvc
   - http://ryrobes.com/python/running-python-scripts-as-a-windows-service/
   - http://wiki.pylonshq.com/display/pylonscookbook/How+to+run+Pylons+as+a+Windows+service
 
 - Using Apache. You can investigate here:
 
   - https://groups.google.com/group/rhodecode/msg/c433074e813ffdc4

scripts/dbmigrate-test

@@ -1,121 +1,121 b''
 #!/bin/sh -e
 
 if [ $# -lt 2 ] || [ $# -gt 3 ]; then
     cat >&2 <<EOD
 usage: $0 CONFIG_FILE FROM_REV [TO_REV]
 
 Runs a database migration from FROM_REV to TO_REV (default: current
 working directory parent), using the specified CONFIG_FILE (.ini file).
 
 Test is run using a clean Kallithea install, in a temporary virtual
 environment. FROM_REV and (optional) TO_REV should be Mercurial revision
 identifiers (e.g. changeset hash or a version number tag). The working
 directory is not touched, but the database referenced in the config file
 will be (re)created.
 
 Only SQLite is available out of the box; for MySQL or PostgreSQL, set
 the EXTRA environment variable to the required package(s), and it'll
 be installed in the virtual environment. (E.g. EXTRA=MySQL-python or
 EXTRA=psycopg2.)
 
 The temporary directory is not removed, allowing follow-up examination
 of the upgrade results. It is, however, created in /tmp by default,
 which many Linux distributions automatically clean at regular intervals.
 EOD
     exit 1
 fi
 
 config_file=$(readlink -f "$1")
 from_rev=$2
 to_rev=$3
 source_repo=$(dirname "$(dirname "$(readlink -f "$0")")")
 
 announce() {
     echo
     echo "$1"
     echo
 }
 
 quiet_if_ok() (
     local output
     local st
     set +e
     output=$("$@" < /dev/null 2>&1)
     st=$?
     if [ $st -ne 0 ]; then
         echo "$output" >&2
         echo "Command $@ returned exit status $st." >&2
         exit 1
     fi
 )
 
 HG() {
     "${HG:-hg}" --repository "$source_repo" "$@"
 }
 
 # If upgrading to "current revision", warn if working directory is dirty.
 if [ ! "$to_rev" ] && [ "$(HG status -mard)" ]; then
     announce "Warning: Uncommitted changes in working directory will be ignored!"
 fi
 
 from_rev_hash=$(HG id --id --rev "${from_rev:-.}")
 to_rev_hash=$(HG id --id --rev "${to_rev:-.}")
 temp=$(readlink -f "$(mktemp --tmpdir -d 'dbmigrate-test.XXXXXX')")
 
 cat <<EOD
 Config file:    $config_file
 EOD
 sed -n -e 's/^sqlalchemy\.url *= */Database URL:   /p' "$config_file"
 cat <<EOD
 Working dir:    $temp
 Repository:     $source_repo
 Upgrade from:   $from_rev_hash (${from_rev:-current})
 Upgrade to:     $to_rev_hash (${to_rev:-current})
 Extra packages: ${EXTRA:-(none)}
 EOD
 
 mkdir "$temp/repos" # empty
 
 # Enable caching for old pip versions (this will cache the pip upgrade)
 # Newer pip versions cache automatically, and don't use this variable.
 if [ ! "$PIP_DOWNLOAD_CACHE" ]; then
     export PIP_DOWNLOAD_CACHE=$HOME/.cache/pip/legacy
 fi
 
 install_kallithea() {
     local prefix=$1
     local rev=$2
 
     announce "Installing Kallithea $rev in $prefix..."
 
     "${VIRTUALENV:-virtualenv}" --quiet "$prefix-env"
     HG archive --rev "$rev" "$prefix"
 
     (
         cd "$prefix"
         . "$prefix-env/bin/activate"
-        pip install --quiet --upgrade pip setuptools mercurial $EXTRA
+        pip install --quiet --upgrade pip "setuptools<67" mercurial $EXTRA
         pip install --quiet -e .
     )
 }
 
 install_kallithea "$temp/from" "$from_rev_hash"
 (
     cd "$temp/from"
     . "$temp/from-env/bin/activate"
     announce "Initializing database..."
     quiet_if_ok kallithea-cli db-create -c "$config_file" --repos="$temp/repos" --user=doe --email=[e-mail] --password=123456 --no-public-access --force-yes
     alembic -c "$config_file" current -v
 )
 
 install_kallithea "$temp/to" "$to_rev_hash"
 (
     cd "$temp/to"
     . "$temp/to-env/bin/activate"
 
     announce "Commencing database upgrade from shown Alembic revision to head..."
     alembic -c "$config_file" current -v
     alembic -c "$config_file" upgrade head
     announce "Upgrade complete, now at the shown Alembic revision:"
     alembic -c "$config_file" current -v
 )

scripts/validate-commits

@@ -1,74 +1,74 b''
 #!/bin/bash
 # Validate the specified commits against test suite and other checks.
 
 if [ -n "$VIRTUAL_ENV" ]; then
     echo "Please run this script from outside a virtualenv."
     exit 1
 fi
 
 if ! hg update --check -q .; then
     echo "Working dir is not clean, please commit/revert changes first."
     exit 1
 fi
 
 revset=$1
 if [ -z "$revset" ]; then
     echo "Warning: no revisions specified, checking draft changes up to the current one."
     revset='draft() and ancestors(.)'
 fi
 
 venv=$(mktemp -d kallithea-validatecommits-env-XXXXXX)
 resultfile=$(mktemp kallithea-validatecommits-result-XXXXXX)
 echo > "$resultfile"
 
 cleanup()
 {
     rm -rf /tmp/kallithea-test*
     rm -rf "$venv"
 }
 finish()
 {
     cleanup
     # print (possibly intermediate) results
     cat "$resultfile"
     rm "$resultfile"
 }
 trap finish EXIT
 
 for rev in $(hg log -r "$revset" -T '{node}\n'); do
     hg log -r "$rev"
     hg update "$rev"
 
     cleanup
     python3 -m venv "$venv"
     source "$venv/bin/activate"
-    pip install --upgrade pip setuptools
+    pip install --upgrade pip "setuptools<67"
     pip install -e . -r dev_requirements.txt python-ldap python-pam
 
     # run-all-cleanup
     if ! scripts/run-all-cleanup ; then
         echo "run-all-cleanup encountered errors!"
         result="NOK"
     else
         if ! hg update --check -q .; then
             echo "run-all-cleanup did not give clean results!"
             result="NOK"
             hg diff
             hg revert -a
         else
             result=" OK"
         fi
     fi
     echo "$result: $rev (run-all-cleanup)" >> "$resultfile"
 
     # pytest
     if py.test; then
         result=" OK"
     else
         result="NOK"
     fi
     echo "$result: $rev (pytest)" >> "$resultfile"
 
     deactivate
     echo
 done

scripts/validate-minimum-dependency-versions

@@ -1,52 +1,52 b''
 #!/bin/bash
 # Test that installation of all dependencies works fine if versions are set to
 # the minimum ones.
 
 set -e
 
 if [ -n "$VIRTUAL_ENV" ]; then
     echo "This script will create its own virtualenv - please don't run it inside an existing one." >&2
     exit 1
 fi
 
 cd "$(hg root)"
 
 venv=build/minimum-dependency-versions-venv
 log=build/minimum-dependency-versions.log
 min_requirements=build/minimum-dependency-versions-requirements.txt
 echo "virtualenv: $venv"
 echo "log: $log"
 echo "minimum requirements file: $min_requirements"
 
 # clean up previous runs
 rm -rf "$venv" "$log"
 mkdir -p "$venv"
 
 # Make a light weight parsing of setup.py and dev_requirements.txt,
 # finding all >= requirements and dumping into a custom requirements.txt
 # while fixating the requirement at the lower bound.
 sed -n 's/.*"\(.*\)>=\(.*\)".*/\1==\2/p' setup.py > "$min_requirements"
 sed 's/>=/==/p' dev_requirements.txt >> "$min_requirements"
 
 python3 -m venv "$venv"
 source "$venv/bin/activate"
-pip install --upgrade pip setuptools
+pip install --upgrade pip "setuptools<67"
 pip install -e . -r "$min_requirements" python-ldap python-pam 2> >(tee "$log" >&2)
 
 # Treat any message on stderr as a problem, for the caller to interpret.
 if [ -s "$log" ]; then
     echo
     echo "Error: pip detected following problems:"
     cat "$log"
     echo
     exit 1
 fi
 
 freeze_txt=build/minimum-dependency-versions.txt
 pip freeze > $freeze_txt
 echo "Installation of minimum packages was successful, providing a set of packages as in $freeze_txt . Now running test suite..."
 
 pytest
 
 echo "Test suite execution was successful."
 echo "You can now do additional validation using virtual env '$venv'."