GitLab

From py3.3 on a subset of virtualenv is built-in, so you can run '-m venv' ot of
the box.

- replace: $(PY_ENV_BIN)/pip --> $(PY_ENV_BIN)/python -m pip
- remove obsolete virtualenv-exe target and adjust VTENV_OPTS
- remove obsolete msg-pip-exe target
- print list of py launchers available from $(PY_ENV_BIN) to the log
- fix hard coded ./local
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

[fix] travis: fix docker build.

[fix] template: fix typo in about.html

export build variables / support brands

And add 'buildenv' as an first order prerequisite to the main targets:

- install
- run
- docs
- docs-live
- project
- node.env
- docker
- test
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Commit 8a16903a removes Makefile target style
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

To Makefile target brand, add creation of bash environment in::

  utils/brand.env

In bash scripts (manage.sh) source env by::

  . utils/brand.env

manage.sh help: show GIT_URL and more environment
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

style.legacy could be renamed themes.legacy : it actually builds the files for
the legacy theme, then themes.legacy can be a dependency of themes.  Same for
the other styles.*

Debatable: about style.bootstrap, same convention : theme.bootstrap (even it is
more a toolbox for the oscar theme).

So there is no need to add the missing make styles in the help target.

thanks @dalf:

- https://github.com/asciimoo/searx/pull/1900#discussion_r399160355Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

The make docker target spits out some SyntaxError.  With this .dockerignore
there is no more error. Explanation:

- the python files are compiled while building the docker image
- a node modules contains some python files
- the python files inside the node module doesn't compile

It raises the fact that node_modules were included in the docker image which
should not happen.  Same the local directory was included.  Dockerfile builds
searx in its own way (without virtualenv)

Thanks @dalf:

- https://github.com/asciimoo/searx/pull/1900#issuecomment-604892737Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

To build all styles use:

  make styles

To build individual styles use one of:

  make style.legacy
  make style.courgette
  make style.pixart
  make style.bootstrap
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Even if we do not versioning them right now.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Update searx/data/useragents.json with the most recent versions of Firefox.

BTW: add 'useragents.update' to 'project' target and clean up the Makefile and
remove it from the manage.sh script.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

closes: https://github.com/asciimoo/searx/issues/1882

The *about* page should only address higher-level issues that are important to
each user.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

A *brand* of searx is a fork which might have its own design and some special
functions which might bee reasonable in a special context.

In this sense, the fork might have its own documentation but not its own issue
tracker.  The *upstream* of a brand is always https://github.com/asciimoo from
where the brand-fork pulls the master branch regularly.  A fork which has its
own issue tracker is a spin-off and out of the scope of the searx project
itself.  The conclusion is:

- hard code ISSUE_URL (in the Makefile)
- always refer to DOCS_URL
- links in the about page refer to the *upstream* (searx project)
  except DOCS_URL
- "fork me on github" ribbons refer to the *upstream*
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

E.g. helpful for searx-stats2
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

We have some variables in the build environment which are also needed in the
grunt process when building themes.  Theses variables are relavant if one
creates a fork with its own branding.  We treat these variables under the term
'brands'.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

We have some variables in the build environment which are also needed in the
setup.py process.  Theses variables are relavant if one creates a fork with
its own branding.  We treat these variables under the term 'brands'.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

We have some variables in the build environment which are also needed in the
sphinx-process.  Theses variables are relavant if one creates a fork with
its own branding.  We treat these variables under the term 'brands'.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

We have some variables in the build environment which are also needed in the
templating process.  Theses variables are relavant if one creates a fork with
its own branding.  We treat these variables under the term 'brands'.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>