Packaging an app
There’s a lot I don’t know. I’ve had to deduce enough to do what I want to do. I can’t find a scrap of documentation online.
Making an app
This is documented, and straightforward. You can handwrite the files inside a Django project, or there is a convenience method which builds the basics,
./manage.py startapp appname
Then you register the app, usually, in ‘settings.py’, and away you got, writing code.
So far, straightforward.
Package your app
Right, there is insanity behind this. I’ve disposed of the insanity. Here is how I do it.
Develop your app in a Django. Key point. Listen to me. Your Django must be developed in a Python virtual environment. Not in a Docker container, or using OS packaging, or whatever else you may think of.
Develop your app. Follow the info at Django documentation, or wherever is comfortable. Don’t knock yourself out trying to finish the app, don’t make it ‘professional’. Don’t worry about people looking at it—they won’t. Don’t worry about diluting the raw power of the Python environment. Think about this—there is little or no help. App packaging, OS stringing and algorithmic theoretics are where computer people dump all that is vicious in their personalities, and are best avoided. You are going to be put through the grinder. So I advocate social irresponsibility. I’ve seen enough not‐finished apps on PyPi to be able to tell you that you are not alone. Junk something on to PyPi now. Get the drift of what you are doing, and where you need to go.
So, when you have a part‐finished, it‐worked‐yesterday app‐sketch, prepare the app for packaging. Do this,
copy your code to someplace safe, then nest in another directory
Pull the README, LICENCE and similar info stuff like screenshots to the top level directory
Then go down to the app directory, make sure you an have an explicit __init__.py file, even if empty
You need to add lines to the __init__.py file. Start the file with your customised version of,
"""Zowee app for Django. Amazingly fast and makes Django easy as hiring somebody else to make the website. Has so many features I've forgotten, but will play Walk of Life every time someone clicks a link."""
__version__ = '0.0.1'
Right, now do your Github upload or whatever it is you do, to consolidate what you have done so far.
At which point, you may think, “But this is useless! How can I develop an app when it has no environment round it for trial and test?” Wait up.
Now use ‘flit’ to publish the app‐in‐it’s‐new‐directory onto PyPi. All instructions are here. This,
‘pip install flit’
‘flit init’ (generates a toml file)
Check the toml file. It’s probably ok
‘flit publish’
Good stuff—you published. Let’s check it worked. Go back to your Django setup, move the app you made someplace out of the way. I wouldn’t delete it, in case something fails here. Right, ‘pip install’ the newly uploaded app. Now your Django should be working again (unless your app does something strange with file management or the like).
Ye,” you say, “But you havn’t answered ny question. If you think I am going to replace the dev code each time, then copy out, package, release, install, test, uninstall replace the package again… that’s a horrible system!”
I’m not.
The trick
You developed in an Python virtual environment yes? The environment looks like this,
virtualEnvFolder
└─ bin
└─ include
└─ lib
└─ share
└─ anAppDirWithADjango
└─ maybeAnotherAppDirWithADjango
...
Your app was downloaded from PiPy into there. It’s in ‘/lib/python3.8/site‐packages’ or similar.
Now, Python is not C++. Well, when it comes to operating systems, it is, it’s made of naming conventions, symlinks and sellotape. But that is your app in that /lib folder. Because it’s Python, it’s Python code, not a compile/binary lump with elaborate support files. If you edit it, the code in your Django app will respond. Yep, I know, editing package downloads is such a no‐no. But you can. So I suggest, if you want to work on your app, work on the copy in the environment.
Now your process is this. You want to try something new with the app. So you edit it in the environment. If everything goes wrong, this is no problem at all. Use ‘pip’ to uninstall then reinstall. Like a revision system that can rollback. But if you like your changes,
Copy the changes over to the release version of the app
Update the version number in the __initi__.py file
‘flit publish’
Not bad at all.
The negatives of this system? I probably don’t need to explain,
Any professional will tell you never to tamper with a packaging system
There is no test integration
There is no release staging
There isn’t enough commandline action, or any obscure computer languages
What are the positives?
After six months, you will remember what to do
The only DRY packaging system I have ever used. No surplus action, no unnecessary configuration
Start work on code immediately
Your choice.
Afterword
Thankyou to the maker of ‘flit’, and those who worked on PEP517/518. As I foggily think, “It’s not autotools”.