Files
@ d6d3cb5991e2
Branch filter:
Location: kallithea/docs/installation.rst
d6d3cb5991e2
5.6 KiB
text/prs.fallenstein.rst
tests: stabilize Git committer in test_vcs_operations
Git tries to find out name and email in this order:
1. The author can be set e.g. via the `--author` option of `git commit`.
2. If set, the environment variables GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL are taken.
3. If set, various (global) config files are considered.
4. Unless disabled by the user.useconfigonly config, the names and emails are
inferred from various system sources such as various fields from /etc/passwd,
/etc/mailname and the environment variable EMAIL.
The author can be provided on the command line (1), but that is not possible
for the committer.
It is not an option to modify Git’s configuration files, so the result of (3)
depends on the system the tests run on, which should be avoided. A follow-up
patch will try to instruct Git to not read the system Git configuration files.
(4) is also system-dependent. On some systems, (4) is disabled in the Git
configuration. If enabled, Git will try to infer the committer name from the
gecko field in /etc/passwd, but will fail if it is empty. The previous code
passed the environment variable EMAIL to provide the corresponding email
address.
By passing the names and emails via (2), we can set the author and committer
name and email uniformly and prevent Git from using the system-dependent ways
(3) and (4). This will replace the use of of EMAIL. The environment variables
were introduced in 2005, so there should be no backwards compatibility
problems.
The tests will specify --author explicitly in the cases where the actual name
matters. We just need default values that can be used for committing when we
don't care.
We set it as static defaults to:
Author: test_regular <test_regular@example.com>
Commit: test_admin <test_admin@example.com>
Based on changes and research by Manuel Jacob <me@manueljacob.de>.
Git tries to find out name and email in this order:
1. The author can be set e.g. via the `--author` option of `git commit`.
2. If set, the environment variables GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL are taken.
3. If set, various (global) config files are considered.
4. Unless disabled by the user.useconfigonly config, the names and emails are
inferred from various system sources such as various fields from /etc/passwd,
/etc/mailname and the environment variable EMAIL.
The author can be provided on the command line (1), but that is not possible
for the committer.
It is not an option to modify Git’s configuration files, so the result of (3)
depends on the system the tests run on, which should be avoided. A follow-up
patch will try to instruct Git to not read the system Git configuration files.
(4) is also system-dependent. On some systems, (4) is disabled in the Git
configuration. If enabled, Git will try to infer the committer name from the
gecko field in /etc/passwd, but will fail if it is empty. The previous code
passed the environment variable EMAIL to provide the corresponding email
address.
By passing the names and emails via (2), we can set the author and committer
name and email uniformly and prevent Git from using the system-dependent ways
(3) and (4). This will replace the use of of EMAIL. The environment variables
were introduced in 2005, so there should be no backwards compatibility
problems.
The tests will specify --author explicitly in the cases where the actual name
matters. We just need default values that can be used for committing when we
don't care.
We set it as static defaults to:
Author: test_regular <test_regular@example.com>
Commit: test_admin <test_admin@example.com>
Based on changes and research by Manuel Jacob <me@manueljacob.de>.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 | .. _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<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<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`.
|