Drop Vagrant setup

CONTRIBUTING.md

@@ -94,10 +94,6 @@ Creating good pull requests
     sometimes what you want can be done in a different way if the reason for the
     change is known. _What goal is your change trying to accomplish?_
 
-You should also use our [Vagrant config when working on ycmd][dev-setup].
-There's _tons_ of gotchas when setting up the correct environment and they've
-all been worked out for you with Vagrant. Save yourself the trouble and use it.
-
 
 Writing code that runs on Python 2 & 3
 ======================================
@@ -156,6 +152,5 @@ Here's what you should watch out for:
 [build-bots]: https://travis-ci.org/Valloric/ycmd
 [ycmd-users]: https://groups.google.com/forum/?hl=en#!forum/ycmd-users
 [ycmd-tests]: https://github.com/Valloric/ycmd/blob/master/TESTS.md
-[dev-setup]: https://github.com/Valloric/ycmd/blob/master/DEV_SETUP.md
 [python-future]: http://python-future.org/index.html
 [what-else]: http://python-future.org/what_else.html

DEV_SETUP.md → DEBUG.md

@@ -1,29 +1,3 @@
-# Setting up for ycmd development
-
-We use Vagrant for development. The VM will have **all** dependencies already
-set up correctly so you won't have to do anything. (If you find something
-missing, please file a bug.)
-
-NOTE: The virtual machine that is created requires 3GB of RAM, so you likely
-need at least 8GB of RAM to use this environment.
-
-1. Install [Vagrant][].
-2. `cd` into the folder where you checked out ycmd.
-3. `$ vagrant up && vagrant ssh`. This will take a while because the VM is being
-   built and set up. Only needs to happen once though.
-4. You are now in the VM. Run the tests with `$ ./run_tests.py`.
-5. Hack away. When done, exit the ssh connection with `exit`.
-6. `$ vagrant suspend` so that you can quickly get back to hacking later.
-7. Later on: `$ vagrant resume && vagrant ssh`. This will be _much_ faster.
-
-That's it!
-
-You can switch between Python versions with `pyenv global 2.6.6` and `pyenv
-global 3.3.0`.
-
-If you ever feel like you've screwed up the VM, just kill it with
-`vagrant destroy` and then run `vagrant up` again to get to a clean state.
-
 # Debugging the Python layer
 
 There are a number of Python debuggers. Presented here are just a couple of
@@ -83,12 +57,10 @@ See the pyclewn docs for more info.
 If you want to debug the c++ code using gdb (or your favourite graphical
 debugger, e.g. [pyclewn][] in Vim), there are a few things you need to do:
 
-1. Ensure your Python is built with debug enabled. In the vagrant system that's
-   as simple as:
+1. Ensure your Python is built with debug enabled. On Linux that's as simple as
+   installing [pyenv][] and running the commands:
 
 ```sh
-    vagrant up
-    vagrant ssh
     export OPT='-g' # Ensure Python binary has debugging info
     export PYTHON_CONFIGURE_OPTS='--enable-shared --with-pydebug'
     pyenv install 2.7.11 # or whatever version
@@ -120,26 +92,21 @@ debugger, e.g. [pyclewn][] in Vim), there are a few things you need to do:
      - The binary must be signed. See
        https://sourceware.org/gdb/wiki/BuildingOnDarwin
      - You *can not* debug system Python. Again: you *must* use a Python that is
-       *not* the one provided by Apple. Use pyenv. That is the rule.
+       *not* the one provided by Apple. Use [pyenv][]. That is the rule.
        Don't argue.
 
   Don't ask why. It's for security.
 
-3. Here you have choices: either use a Python debugger to break the tests, or
-   manually use Vim to simulate the scenario you want to debug. In any case, you
-   will need the PID of the running Python process hosting ycmd to attach to.
-   Getting this is left as an exercise, but one approach is to simply
-   install vim with `apt-get install vim` and to get a copy of YouCompleteMe
-   into `$HOME/.vim/bundle` and symlink `/vargant` as
-   `$HOME/.vim/bundle/third_party/ycmd`. Anyway, once you have the PID you can
-   simply attach to the Python process, for example:
-
+4. Here you have choices: either use a Python debugger to break the tests, or
+   manually use Vim and [YouCompleteMe][] to simulate the scenario you want to
+   debug. In any case, you will need the PID of the running Python process
+   hosting ycmd to attach to. For example using Vim:
    - `:YcmDebugInfo` to get the pid
    - `gdb: attach <PID>`
    - `break YouCompleteMe::FilterAndSortCandidates`
 
-
-[vagrant]: https://www.vagrantup.com/
+[YouCompleteMe]: https://github.com/Valloric/YouCompleteMe
+[pyenv]: https://github.com/pyenv/pyenv
 [pyclewn]: http://pyclewn.sourceforge.net
-[pyclewn-install]: http://pyclewn.sourceforge.net/install.html
+[pyclewn-install]: https://sourceforge.net/p/pyclewn/pyclewn/ci/default/tree/INSTALL
 [ipdb]: https://pypi.python.org/pypi/ipdb

README.md

@@ -35,8 +35,8 @@ built one.
 
 Building
 --------
-**If you're looking to develop ycmd, see the [instructions for setting up a dev
-environment][dev-setup] and for [running the tests][test-setup].**
+**If you're looking to develop ycmd, see the [instructions for running the
+tests][test-setup].**
 
 This is all for Ubuntu Linux. Details on getting ycmd running on other OS's can
 be found in [YCM's instructions][ycm-install] (ignore the Vim-specific parts).

TESTS.md

@@ -2,29 +2,16 @@
 
 This readme documents instructions on running the test suite.
 
-The easiest way to run the ycmd test suite locally is to [set up your ycmd dev
-environment using Vagrant][dev-setup] which will have everything installed and
-ready to go. Reading this file is still useful because you'll learn how to skip
-the build or parts of the test suite.
-
 An alternative (canonical) reference is the scripts used for running the tests
-on Travis CI. These can be found in `.travis.yml` and `./travis` directory.
+on [Travis][], [CircleCI][], and [AppVeyor][]. These can be found in
+`.travis.yml`, `appveyor.yml`, and the `ci` and `.circleci` directories.
 
 ## Requirements for running the tests
 
-You need to have installed:
-
-* nose (pip install nose)
-* nose-exclude (pip install nose-exclude)
-* mock (pip install mock)
-* flake8 (pip install flake8)
-* webtest (pip install webtest)
-* hamcrest (pip install PyHamcrest)
+You need to have installed all the requirements in `test_requirements.txt`. The
+simplest way to set this up is to use a [virtualenv][], for example:
 
-See `test_requirements.txt` for specific versions. The simplest way to set this
-up is to use a virtualenv, for example:
-
-```bash
+```sh
 $ mkdir ~/YouCompleteMe/tests
 $ virtualenv ~/YouCompleteMe/tests
 $ source ~/YouCompleteMe/tests/bin/activate
@@ -34,11 +21,11 @@ $ pip install -r test_requirements.txt
 You also need to have all of ycmd's completers' requirements. See the
 installation guide for details, but typically this involves manually installing:
 
-* mono
-* gocode
-* typescript
-* node
-* npm
+* [Mono][]
+* [Go][]
+* [Node.js and npm][npm-install]
+* [TypeScript][]
+* [rustup][]
 
 If you are unwilling or unable to install the requirements for all of the
 completers, you can exclude certain completers with the `--no-completer`
@@ -54,36 +41,36 @@ change the paths in `OmniSharpServer/OmniSharp/Solution/CSharpProject.cs`
 
 To run the full suite, just run `run_tests.py`. Options are:
 
-* `--skip-build`: don't attempt to run the build `build.py`, e.g. if you use
-a non-standard build environment (e.g. `cmake28`, self-build of clang, etc.)
-* `--no-completers`: Do not build or test with listed semantic completion engine(s).
-* `--completers`: Only build and test with listed semantic completion engine(s).
-* `--msvc`: The Microsoft Visual Studio version to build with.
- (default: 14). Windows only.
-* `--arch`: Force architecture to 32 or 64 bits on Windows (default: python
-interpreter architecture). Windows Only.
-* `--coverage`: Generate code coverage data
+* `--skip-build`: don't attempt to run the `build.py` script. Useful once
+  everything is built;
+* `--no-completers`: do not build or test with listed semantic completion engine(s);
+* `--completers`: only build and test with listed semantic completion engine(s);
+* `--msvc`: the Microsoft Visual C++ version to build with (default: 15).
+  Windows only;
+* `--coverage`: generate code coverage data.
 
 Remaining arguments are passed to "nosetests" directly. This means that you
 can run a specific script or a specific test as follows:
 
+* Specific script: `./run_tests.py ycmd/tests/<module_name>.py`
 * Specific test: `./run_tests.py ycmd/tests/<module_name>.py:<function name>`
-* Specific script: `./run_tests.py ycmd.tests.<module_name>`
 
 For example:
 
-* `./run_tests.py ycmd/tests/subcommands_test.py:RunCompleterCommand_GetType_test`
-* `./run_tests.py ycmd.tests.subcommands_test`
+* `./run_tests.py ycmd/tests/subcommands_test.py`
+* `./run_tests.py ycmd/tests/subcommands_test.py:Subcommands_Basic_test`
 
-NOTE: you must have UTF8 support in your terminal when you do this, e.g.:
+NOTE: you must have UTF-8 support in your terminal when you do this, e.g.:
 
-    > LANG=en_GB.utf8 ./run_tests.py --skip-build
+```sh
+LANG=en_GB.utf8 ./run_tests.py --skip-build
+```
 
 ## Coverage testing
 
 We can generate coverage data for both the C++ layer and the Python layer. The
-CI system will pass this coverage data to codecov.io where you can view coverage
-after pushing a branch.
+CI system will pass this coverage data to [codecov.io][] where you can view
+coverage after pushing a branch.
 
 C++ coverage testing is available only on Linux/Mac and uses gcov.
 Stricly speaking, we use the `-coverage` option to your compiler, which in the
@@ -95,11 +82,11 @@ automated integration tests.
 
 Run it like this:
 
-```
-$ ./run_tests.py --coverage
+```sh
+./run_tests.py --coverage
 ```
 
-This will print a summary and generate HTML output in `./cover`
+This will print a summary and generate HTML output in `./cover`.
 
 More information: https://coverage.readthedocs.org and
 https://nose.readthedocs.org/en/latest/plugins/cover.html
@@ -108,24 +95,33 @@ https://nose.readthedocs.org/en/latest/plugins/cover.html
 
 ### All the tests fail with some missing package.
 
-Check the list of pip packages to install above. If there is one not listed,
-install it and add it to the list.
+Make sure you have installed all the packages in `test_requirements.txt` with
+`pip install -r test_requirements.txt`.
 
 ### All the CsCompleter tests fail on unix.
 
 Likely to be a problem with the OmniSharpServer.
 
 * Check that you have compiled OmniSharpServer in `third-party/OmniSharpServer`
-* Check that OmniSharpServer starts manually from ycmd/tests/testdata with
-
-    > mono ../../../third_party/OmniSharpServer/OmniSharp/bin/Debug/OmniSharp.exe -s testy/testy.sln
+* Check that OmniSharpServer starts manually from `ycmd/tests/cs/testdata` with
+  ```sh
+  mono ../../../third_party/OmniSharpServer/OmniSharp/bin/Debug/OmniSharp.exe -s testy/testy.sln
+  ```
 
 ### You get one or all of the following failures
 
-    ERROR: ycmd.tests.get_completions_test.GetCompletions_CsCompleter_PathWithSpace_test
-    FAIL: ycmd.completers.general.tests.filename_completer_test.FilenameCompleter_test.QuotedIncludeCompletion_test
-    FAIL: ycmd.completers.general.tests.filename_completer_test.FilenameCompleter_test.SystemPathCompletion_test
-
-Ensure that you have UTF-8 support in your environment (see above)
-
-[dev-setup]: https://github.com/Valloric/ycmd/blob/master/DEV_SETUP.md
+    ERROR: ycmd.tests.cs.get_completions_test.GetCompletions_PathWithSpace_test
+    FAIL: ycmd.tests.filename_completer_test.FilenameCompleter_test.SystemPathCompletion_test
+
+Ensure that you have UTF-8 support in your environment (see above).
+
+[travis]: https://travis-ci.org/Valloric/ycmd
+[circleci]: https://circleci.com/gh/Valloric/ycmd
+[appveyor]: https://ci.appveyor.com/project/Valloric/ycmd
+[virtualenv]: https://packaging.python.org/guides/installing-using-pip-and-virtualenv/
+[mono]: http://www.mono-project.com/download/stable/
+[go]: https://golang.org/doc/install
+[npm-install]: https://docs.npmjs.com/getting-started/installing-node
+[typescript]: https://www.typescriptlang.org/#download-links
+[rustup]: https://www.rustup.rs/
+[codecov]: https://codecov.io/