I'll try to implement django middlewares support in the
Each middleware can return injector subclass.
Next middleware can depend on attributes defined in this subclass.
View can depend on attributes defined by all middlewares.
# In conftest.py from dependencies import ( Injector ) from dependencies.contrib.pytest import ( register ) from server.implemented.process import ( ProcessConfiguration ) from server.tests.stubs import ( do_nothing_stub, retrieve_square_dxf_test_file_stub ) @register class ProcessConfigurationStoryOnSquareFilePatched(Injector): """Replace download file function by a stub retrieving a local test file instead.""" name = 'process_configuration_on_square_file' fixture = ProcessConfiguration download_file = retrieve_square_dxf_test_file_stub upload_file = do_nothing_stub
Hi @proofit404 , sorry, didn't get it fully, can you explain it in case of bookshelf project
class BuySubscription: """Buy subscription for certain category.""" # TODO: Ignore repeated subscriptions. @story @arguments("category_id", "price_id", "profile_id") def buy(I): I.find_category I.find_price I.find_profile I.check_balance # TODO: Create payment record here. I.persist_payment I.persist_subscription I.prepare_subscription_notification I.send_notifications I.show_category
class BuySubscription(Injector): buy_subscription = usecases.BuySubscription.buy load_category = repositories.load_category load_price = repositories.load_price load_profile = repositories.load_profile decrease_balance = repositories.decrease_balance current_date = django.utils.timezone.now create_subscription = repositories.create_subscription send_notifications = current.SendNotifications.send
for example I want to wrap
persist_subscription functions with transaction
In that case, I'll keep the use case and the injector the same way they are.
In the repositories
persist_payment will start the transaction inside the function and
persist_subscription will end a transaction.
To make it more generic you can write
EndTransaction classes. Inject
class MinioInjector(Injector): minio = Minio(**MINIO_CONNECTION) minio_story = MinioStory class FillDataInjector(Injector): elastic = NewsElasticInjector fill_story = FillDataFromElasticStory class ExcelExportInjector(Injector): elastic = FillDataInjector minio = MinioInjector email = mail_send_export_file excel_story = ExportExcelStory class MainExportInjector(Injector): excel = ExcelExportInjector doc = Mock() pdf = Mock() log_story = ExportMainLogStory
Hi there! I came across this library a while back and I really like it. I have used it in one of my projects and it works like a charm. However, assigning classes in the Container definition is throwing mypy off (naturally, it does not know that the variable will actually become a class instance instead of the class). What is the recommended way of using dependencies with mypy? I currently use # type: ignore which is a bit painful.
Hi! Thanks for reaching out!
Indeed, dependencies behavior is way complex for mypy to figure out stuff. We had in mind to write a plugin for mypy to infer types there.
This task turns out to be way too complex to implement. It would take unreasonable amount of time to implement.
I decided to dedicate my time to the features of the library instead.
If you like to write mypy plugin which will at least ignore
dependencies properly, this contribution is more than welcome!
To be honest, dependencies, stories, and mappers do a ton of work to validate things at runtime. So any mypy plugin will duplicate that work.
Have a good day :tada:
These chat rooms left for historical purposes only. All active maintainers of the project have left gitter.
Projects are still properly maintained. If you have any questions, please file an issue in our issue tracker:
Issues are better to keep track of the community interests. It could be converted to tasks easily. It preserves the history of resolution. It's google friendly. Let's keep our conversation in a structured way! See you there.