# Packages required to run load tests
# Using -e for now because neither of these packages have released code
# properly.  Once they have done releases with actualy versions we should
# pin these packages correctly.
-e git+https://github.com/edx/locust.git@edx#egg=locustio[scipy]
-e git+https://github.com/edx/opaque-keys.git@9f07da1abf699d10bc3252d3081017e8aa37c302#egg=opaque-keys

edx-rest-api-client==1.2.1
jupyter
runipy
seaborn
lazy

# Packages required to run load tests
# Using -e for now because none of these packages have released code
# properly.  Once they have done releases with actualy versions we should
# pin these packages correctly.
-e git+https://github.com/edx/opaque-keys.git@9f07da1abf699d10bc3252d3081017e8aa37c302#egg=opaque-keys

locustio==0.7.3
edx-rest-api-client==1.2.1
jupyter
runipy
seaborn
lazy

Stop using fork of locust to unblock loadtests
Stop using fork of locust to unblock loadtests

Sometime in the last 30 days, using our fork of locust broke locust's ability to drive significant load. I observed the following behavior:

* Request 200 users at 10 users/s
* Locust begins spawning users at the requested rate, req/s increases linearly with users
* Locust user spawn rate and req/s start decreasing. Req/s levels off to a test-specific constant (varies between tests but not between runs of tests)
* Locust continues to spawn users albeit at a vastly lower rate. Req/s decrease slowly

Switching to the standard locust distribution solves the issue.