So the test are still passing. If I broke anything, we should consider adding a test for that. 😇

@bastiencyr: Also, my apologies, if this changes much of your earlier PR. I just felt some things could be solved in a simpler way. I still envy the general idea and I'm happy I took the time to understand it in details.

I have to admit that Im a little be disappointed but it was necessary 😢😢
Some things was useless like all my prints everywhere, the timeout and some functions like load_from_db. But some important things has been removed (mutex, getters).

Thanks for understanding. My goal is also to help future coders understand it. The main idea of using one queue and worker per repo/site is still there and it was brilliant!

I can put the mutex stuff back. What is it needed for and can we add a test to test for the problem?

* Combine `borg.jobs_manager.Job` with `borg.borg_job`

Its not a good idea. The Job class add an abstraction (interface) and separate jobs manager from jobs itself. By doing this, it becomes difficult to know what jobs managers need (for example a repo_id function, a site_id property...). It will be difficult for another dev to rewrite the jobs manager if needed.

Its not a good idea. The Job class add an abstraction (interface) and separate jobs manager from jobs itself.

OK. Undoing again. Also looking at locks real quick.

Put back your JobInterface, so it's all in one place.

And added some locks and checks to avoid dupe jobs.

Please help improve, so we get a good PR.

Sorry @m3nu , I have an hackathon this week end so basically more than 20 hours of code 😅
I will tried to help the evening but if it can wait a little, its better 🙄

No worries. All the best for the hackathon! I value your opinion and feedback, so will just keep it open here.

Hello @m3nu I look at this today !

Is there something else you need @m3nu ?
I let some comments