Django 4.2 released
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/apr/03/django-42-released/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7dbf7d40-41a3-832a-ef7f-968bdf5490c1%40gmail.com.
Implement Ruff Linter
Hi ! I use Ruff as my primary Linter for all my Python Projects. https://github.com/charliermarsh/ruff It's very fast and powerful, so I thought I could try it on Django Code. With all options activated, Django is scanned in less than 1 second. Here's the Configuration with all detected errors types ignored. https://github.com/django/django/compare/main...obi-jerome:django:Ruff What do you think ? Is it done the proper way ? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c3201044-4d25-49d3-b0ce-06de4c7624efn%40googlegroups.com.
Re: The problem of versioning a large project.
I'm not sure your issue is Django-specific, so it may be off-topic for this group. However, your question is a bit vague to be appropriate for Stack Overflow or other forums either. "Versioning" could mean a few things. At first, I thought you meant something like date-based or semantic versioning. It sounds like you are talking about code repository organization, and how to integrate the work of several apps or teams. In my experience, this is a people and process problem first, and a code issue second or third. My first advice would be to abandon a git repo per app and combine everything into a single repo, where all the code is in one repository. I find this much easier to work with and to collaborate with other developers, especially on a web project where deployment is frequent and mostly automated, and especially using a tool like GitHub or GitLab. A separate branch and a pull request is used to bring in new features and bug fixes. Reviewers are assigned based on the areas touched, and GitHub has features like code owners to automate review assignment. The HEAD is the latest version, and the git tag feature can be used to identify key versions like releases. I prefer a repo per "project", which may have several deployed "containers", such as a web frontend, an API, a background processor, and periodic tasks. We often use Docker containers to collect the project into an executable package, and use different entrypoints in the same image for the different containers. Some companies have taken the single repo to the extreme of a "monorepo", a single codebase for all the company's projects. This makes code sharing possible across projects, but also requires a lot of tools and process to manage the repo and changes to it. Google's monorepo is a famous example. Mozilla's repo for Firefox / Gecko has similar qualities, including a custom search website, a pull request review system, and their own continuous testing architecture. I don't recommend this level of monorepo except for huge projects with hundreds of committers and the budget for dedicated build staff. If you continue with multiple repos, the "git submodule" feature specifically supports a git repo inside another git repo. Updating a submodule to a different version is a commit in the "parent" project. I find submodules awkward to use, but useful for truly parallel work. At Mozilla, we often use a git submodule for translated strings. The translation team makes several daily commits to add new translations. A github action updates the submodule to the latest version overnight. To add new strings, we open a pull request on the translation repo. If you decide to continue with separate repos per app, and further split to a frontend repo, the first question is "how many?" A single frontend repo could have the templates for all your projects. This would require good documentation and standardization for your view code, so that the templates could be coded without necessarily peeking at the view code. Many complex Django apps, such as django-allauth, ship simple base templates with instructions for overriding them to match the feel of your website. Another method would be for your app to expose an API, and build the frontend on another technology like React. The frontend would call a RESTful API implemented in django-rest-framework or similar. You could use nginx to serve the frontend files, or a Django app like whitenoise. This would allow the frontend developers to work independently from the backend Django devs. I've found that even in this case it is useful for a frontend dev to have access to backend code, to coordinate a change or understand an API, and sometimes it is easier for the backend dev to fix something in the frontend. I still recommend a single repo, even with a frontend / API separation. I suspect you have constraints you have not mentioned, such as using external contractors and not wanting them to have access to some of the code. If this is the case, separate repos may be the best way to split the code, and give access to some but not others. This is still doing things the hard way! If possible, work with reliable people with contracts to remove those barriers. If not, make the code work for your business constraints, such as an API to give a clean separation between insiders and outsiders. I hope this helps John On Sunday, April 2, 2023 at 11:52:25 AM UTC-5 Alex Sonar wrote: > It is about one project that includes many applications. > > We would like to separate the repository specifically for front-end guest > groups. > > With access to parts like: views_groups, templates, dummy_data, > forms_group, helpers_group, static_blob and media_blob as an example. > > Now our application tier and the file structure of the project looks > something like in the picture below. > > >. > > ├── apps > > . ├── .DS_Store > >├── app_alpha > >
Re: Fellow Reports - March 2023
Week ending April 2, 2023 *Triaged:* https://code.djangoproject.com/ticket/34438 - UserCreationForm.clean_username() crashes with a custom user model. (accepted) https://code.djangoproject.com/ticket/34439 - mod_wsgi for django with conda environment in Windows doesn't work (invalid) https://code.djangoproject.com/ticket/34441 - A new require_files decorator for file validation in Django Framework (wontfix) https://code.djangoproject.com/ticket/34442 - runserver is slow to accept http connexions when running on 0.0.0.0 (needsinfo) https://code.djangoproject.com/ticket/34443 - Filtering reverse relations against invalid lookups crashes. (created) https://code.djangoproject.com/ticket/3 - Summing through a One-to-Many relationship on the property of a JSONField fails (invalid) https://code.djangoproject.com/ticket/34446 - Coding style docs should contain incorrect example for Model style. (accepted) https://code.djangoproject.com/ticket/34447 - Support backgroup async repeat task. just like fastapi_utils.tasks.repeat_every (wontfix) https://code.djangoproject.com/ticket/34448 - makemessages' --no-obsolete option is undocumented and untested. (accepted) https://code.djangoproject.com/ticket/34449 - ProgrammingError: non-integer constant in GROUP BY with Case When and annotate Count (fixed) https://code.djangoproject.com/ticket/34452 - Report the correct port when using port 0 with runserver (duplicate) *Reviewed/committed:* https://github.com/django/django/pull/16602 - Fixed #28948 -- Optimized CookieStorage performances. https://github.com/django/django/pull/16678 - Fixed #34383 -- Fixed layout of admin fieldsets with multiple fields on the same line. https://github.com/django/django/pull/16661 - Fixed #28384 -- Fixed ModelAdmin.lookup_allowed() for foreign keys as primary key. https://github.com/django/django/pull/16690 - Fixed #34438 -- Reallowed extending UserCreationForm. https://github.com/django/django/pull/16693 - Fixed #34427 -- Improved error message when context processor does not return a dict. https://github.com/django/django/pull/16697 - Fixed overindentation of AdminURLFieldWidget. https://github.com/django/django/pull/16706 - Fixed #34446 -- Removed unneeded and incorrect example in coding style docs. https://github.com/django/django/pull/16707 - Fixed #34445 -- Fixed string-casting of non-string lazy objects. *Authored:* https://github.com/django/django/pull/16694 - Refs #29799 -- Added field instance lookups to suggestions in FieldErrors. https://github.com/django/django/pull/16695 - Fixed #34443 -- Fixed filtering by transforms on reverse relations. https://github.com/django/django/pull/16700 - Bumped versions in pre-commit and npm configurations. https://github.com/django/django/pull/16702 - Refs #34383 -- Corrected margins in admin fieldsets with multiple fields on the same line on small screens. https://github.com/django/django/pull/16704 - Reverted "Refs #31949 -- Enabled @sensitive_variables to work with async functions." https://github.com/django/django/pull/16708 - Updated release process for 2.0+ release numbering and latest practices. Best, Mariusz -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/650893b4-354d-4f46-bd2e-30a96801d695n%40googlegroups.com.
