I tend to never use Django Extensions except something like mysqlclient, which I have to. The reason is that they never work for me. I just tried to install django-filer, which seems like a cool extension that is also used in django-cms. After installation, nothing works because a couple of imports are broken. I go to site-packages and fix it manually. Then I end up with
C:\Users\Dev\Envs\rbp_website_venv\lib\site-packages\filer\fields\file.py:134: SyntaxWarning: FilerFileField can only be a ForeignKey to filer.File; filer.file passed warnings.warn(msg, SyntaxWarning)
So I reset the db, erase all migrations, try again. I end up with:
django.core.exceptions.FieldError: Auto-generated field 'file_ptr' in class 'Image' for parent_link to base class 'File' clashes with declared field of the same name.
And this is pretty much the experience I always have, when I try to install extensions. They never work out of the box and I usually end up with something like this. I don’t even know where I should look to fix the above error. Also, when I have to manually change packages that I installed, I can’t really update them. Using a package usually ties you to a particular django version, however I like to keep my django version up to date, and so on.
Is this just me or is there other people who find extensions rather unusable for similiar reasons?
I can’t imagine doing any Django development without about a dozen additional packages installed.
First, managing paths in a Windows environment can be a pain - granted - but it is manageable. Making sure the right paths and directories are being referenced can take some effort depending upon how you have things set up. But the key is making sure you’re consistent when working with it - especially when it comes to virtual environments.
But I will say, if you have any way at all of doing your development within a “Linux-style” environment, you will find it a lot easier that way. It doesn’t matter much whether it’s a Linux server accessed remotely, virtual machine using VirtualBox or VMWare, or the Windows Subsystem for Linux (WSL).
I think I misread the django-filer specs. When they wrote that it’s compatible with Django 1.8 =>, Django 3 wasn’t out yet and therefore isn’t mentioned. I don’t think the Windows environment is necessarily the problem. Windows 10 is a lot friendlier in that regard.
There’s something else that I find worrysome. Let’s say I include django-filer into my project now. It replaces the FileFields. That means that all my model file associations rely on django-filer. So if in the future, django-filer is no longer maintained or supported for some reason, it would break a very central mechanic of my project. And I don’t know how to remove django-filer without breaking the associations.
That’s a fundamental issue with any open source project.
Part of the risk of implementing a project using Open Source software is the tacit acknowledgment that you, at any time, might be responsible for fixing anything. Part of that process may mean forking the source repo, and performing your own merges from the original when they occur.
Now, if you find a well-established project (such as Django) with a mature community and process, that risk is minimized. But the risk still exists.
Part of the evaluation of any related or third-party project should be the examination of how viable that project may be, and whether or not you’re able to pick up and support the project yourself should the need arise.
This is something that everyone (especially commercial enterprises) needs to be reminded of at times. Open Source may mean no initial cost of entry, but may mean significant developer effort over time. In the words of an old television commercial, “You can pay me now, or you can pay me later.”
The django-filer project suffers a bit under its own complexity. I couldn’t imagine working with Django without 3rd party packages either, but I agree that a few of them could use some pruning in terms of features they offer and code that is required for those features.
That being said, saying no is much harder than saying yes and it just happens too often that a small library ends up big and framework-like without the community to support it.
I think I was too impatient again. I misread a version declaration. Django-Filer is not yet compatible with Django 3.1. So I’ll give it another try when it is.
Sorry for the self promotion but you may also want to take a look at django-cabinet: https://github.com/matthiask/django-cabinet/