Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
make sure the current working dir is in the sys.path #484
I maintain multiple load tests, each with their own locustfile. They each
Then I invoke locust from the project root:
locust -f path/to/locustfile
I think it's understandable why
from locustfile import MyLocustClass
""" Load test suite 1 """ from locust import Locust, task, TaskSet # our custom shared helper modules import helpers class MyTaskSet(TaskSet): @task(1) def some_task(self): pass class MyLocustClass(Locust): task_set = MyTaskSet
testing running locust without this patch
Before this change, the common
testing running locust with this patch
Your use case is very similar to how I and many others use locust. Unfortunately, I'd be worried about this breaking people's integrations or having unintended side effects depending on where you are running from and if you have modules or packages with the same name across your project.
What I'd like to see before this gets merged is some best practices documentation for structuring a non-flat locust project. Trying to standardize project structures and import paths to some extent will make them easier to support in the future. I made #500 to track that separately, but feel free to take a first stab if you're up for it.
@heyman What is your opinion on this? I agree that it may be a bit disruptive to existing tests because it changes how locust runs. But I do think people expect to be able to import modules in the same fashion as if they had run
I understand the issue but I'm a little bit hesitant because of potential negative effects it might have (that are currently unknown to me). But I think I'm +0 at the moment.
#1112 that was just merged makes it possible to avoid the issue by starting locust using