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_r399160355
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>
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
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>
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>
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>
To get meaningfull diffs, the json file has to be sorted. Before applying any
further content patch, the json file needs a inital sort (without changing any
content).
Sorted by::
import sys, json
with open('engines_languages.json') as f:
j = json.load(f)
with open('engines_languages.json', 'w') as f:
json.dump(j, f, indent=2, sort_keys=True)
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
With the aim to simplify development cycles, started with PR #1756 a Makefile
based boilerplate was added. This patch adds the missing developer
documentation.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
- add sphinx extensions
- patch documentation to make use of
These modules help to simplify the reST markup of external references. BTW it
helps to write more readable reST and form custom brands.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
Add *Makefile* boilerplate useful for python projects. All python tasks are
using a virtualenv from ./local/py3
$ make help
run - run developer instance
install - developer install (./local)
uninstall - uninstall (./local)
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
Markus Heiser