from #2463 (comment) ..

If that doesn't affect the existing searxng installations with the script (you are technically the only one to know that), I'm for reviewing and merging that PR.

I hesitate to review/merge, since the colon is a very core concept of the methods that install templates, see option --variant=<name>:

This is just one point comes first into my mind .. may be there is more to do .. and it needs a lot of testing ..

If we want touch this core methods we need good reasons for .. is to clone on windows such a good reason even when we will never support this platform? .. I don't think so, but this is my personal opinion.

I'm for not restricting people from trying to use searxng on Windows, at the end of the end we both know that searxng being written in python will work on Windows.

Thanks for the pointers about the other potential script breaking. Couldn't we move the install scripts to another repository? Similar to what we already have with https://github.com/searxng/searxng-docker

Couldn't we move the install scripts to another

On a (very) long term yes (may be) .. @dalf already asked for this multiple times in the past .. but this is a huge task .. we have a lot of shell scripts in the development- test- and deployment- cycles that make use of the lib.sh I linked above.

By example most of the installation instructions are generated by theses scripts and my tests on distributions we support are based on this scripts.

These changes will have far-reaching consequences, it will affect the CI, the way we develop today and it will affect all instances that have been built up to now.

I have already started to modularize the shell scripts a bit to be able to remove parts of them gradually. I always have this in mind, but I don't see it as a task that can be done in one step ... the implications are too far reaching .. and I do not have alternatives at hand to generate documentation or test on various distributions ..

I know there are a lot of test & build tools but they often need a infrastructure to setup first .. while these scripts are all running on a desktop or laptop .. These scripts can setup a build & test host in minutes https://docs.searxng.org/admin/buildhosts.html#buildhosts and with LXC the scripts scale over all distributions .. https://docs.searxng.org/dev/lxcdev.html

Do you notice where we started: with one person who can't check out a clone on Windows and because of a colon we start to question everything ..

I am alone with the development and would like to devote myself to more important issues that improve the product ... all these issues we discuss because of a colon do not bring SearXNG forward from a user point of view.

To be honest, as long as there are no really good reasons, I would like to postpone the topic to the future.

I mark this PR as draft for now.

I'm for not restricting people from trying to use searxng on Windows, at the end of the end we both know that searxng being written in python will work on Windows.

Thats not true in deep .. SearXNG is a infrastructure deployed by docker container or installed by scripts. To name just two examples .. in the future redis becomes mandatory and there are hard coded concepts like the configuration expected under /etc/searxng .. If we open the door a crack for an MS Windows ecosystem, more requirements will come and we have to handle all aspects in the MS-Windows ecosystem .. and this was never the intention of SearXNG.

I'm for not restricting people from trying to use searxng on Windows, at the end of the end we both know that searxng being written in python will work on Windows.

Thats not true in deep .. SearXNG is a infrastructure deployed by docker container or installed by scripts. To name just two examples .. in the future redis becomes mandatory and there are hard coded concepts like the configuration expected under /etc/searxng .. If we open the door a crack for an MS Windows ecosystem, more requirements will come and we have to handle all aspects in the MS-Windows ecosystem .. and this was never the intention of SearXNG.

I strongly disagree, plenty of people are not deploying searxng with the install scripts or docker containers, and we shouldn't let down these peoples.

Also I don't want to have redis as a hard requirement, we should offer features that benefit from having redis, but we should not make it a hard requirement. Running a simple searxng with just python should still be possible. Anyway it's probably going off topic and this should be discussed elsewhere.

Anyway, on to the topic, like I said I don't want to restrict Windows users nor anyone running on another OS from trying to contribute to the project. If we want more contributors, we must not introduce too many barriers, or they will just never try the project.

I'll one day try if these changes in this PR break existing installations.

So that other OS like Windows can clone the repository: #2463

The issue is related to the underlying filesystem / these path names are not needed on MS-Win / git config --global core.protectNTFS false should help on MS-Win filesystems.

git config --global core.protectNTFS false is not a solution:

If set to true, do not allow checkout of paths that would cause problems with the NTFS filesystem

Also:

• SearXNG is a python application which actually works on Windows without issue (there are just few lines to change to make OS agnostic).
• we don't have to provide support for Windows, just unlock the access.
• the issue is with files that I always thought that should be a different repository (the fact the repository clones itself is big sign).

I've lost hope that you change your mind on this subject.

the issue is with files that I always thought that should be a different repository (the fact the repository clones itself is big sign).

You are absolutely right, I would also like to remove all installation scripts from SearXNG in the long term. I have often made a start, but then there are always so many other tasks in between that are more urgent.

I just want to save myself the extra work of touching the installation scripts again in the meantime. Even if it looks like a small thing, I have to do several tests (on all distros we support) ...

I've lost hope that you change your mind on this subject.

If it is explicitly desired, then we can reopen the issue and thie PR ... sadly I still don't have time for that.

Don't have time for that anymore.