The Idea
I had to focus my efforts in python-blogger-refresh-part-1 on restoring the original functionality of my Python Blogger script. That’s out of the way. I can now start looking at enhancements. The first annoyance - of many - is the fact that Blogger connection settings are hard-coded into the script. Do you want to post to a different blog? That’s going to require editing the source.
Let’s fix that three ways:
- Adding the ability to define connection details from the command line
- Adding the ability to define connection details from a config file.
- Adding the ability to interactively request connection details when they have not been specified on the command line or in a config file.
From the Command Line
We’re already using optparse , so adding the ability to define connection settings from the command line won’t be difficult. Three options are needed:
- Author Name
- Password
Add those options in main
with parser.add_option
.
Let’s see how that behaves. First I’ll try using the old way, which is now the wrong way.
That DeprecationWarning
is coming from inside GData. I won’t worry about it for the moment, but I will keep my eyes open for new releases.
Anyways, how about when running it correctly?
A quick look at the drafts in my Blogspot dashboard confirms that the code works. That command line has gotten a bit long, though. How about adding a config file?
From a Config File
It’s good to have a configuration file holding most of your details. We can keep sensitive information out of the application code, and not have to remember them on the command line every time we run the script.
I am going to make a separate config
directory to hold my config. Why? This makes it easier for me to expand my definition of what a configuration is. If I want to use non-core Markdown extensions later - and I will - I can place them here rather than dirtying my Python site-packages
folder. Or dist-packages
, in Ubuntu’s case. Why do they always have to be different?
The actual config file will be a simple ini-style file spiked with key=value lines. Here’s mine:
The ConfigParser library will be used to handle opening and reading in these options. Using both a config file and command line parsing is going to require poking a little bit at everything, so I’m going to move along slowly.
In main
, I’ll set up the ConfigParser.
The application reads the configuration file before handling the command line to set up the normal behavior. It still processes the command line, though. Maybe I don’t want to keep all of my information in the config, or maybe I’m posting to a completely different blog.
It’s nice to get the settings both ways, but I think we can be a little nicer still.
Interactively
What if there’s no config file, or the config file is incomplete, and there are still missing pieces even after parsing the command line? The behavior I would hope for in an app like this is that it would ask me to fill in the missing blanks. Might as well allow the post filename to be one of the blanks.
Hey, it works and I don’t even have to use a config file if I don’t want to!
The only problem is that now I’ve messed up the way testing behaves.
That’s easy enough to fix. I’ll just exit after running the tests. You would think I would have noticed that before. Why would I? I never used the -f
flag at the same time as the -D
flag, so this issue wouldn’t have come up.
Let’s stop here and get ready for the next leg.
What Was Accomplished
At the start of this post, we had a script which would submit a blog posting based on a filename command parameter, using connection settings that were hard-coded into the script. After a little fiddling around, we’ve added the ability to get all connection details from the command line, from a configuration file, from interactive input, or some combination of all three. That’s a pretty big step in making this blog post code more useful for people who aren’t me.
Next Time
This code gets the job done, but I will freely admit that this code is getting ugly. Half the application has tests, and the other half is in main
. Next time I visit this code I’ll have to take a long hard look at refactoring and maybe adding some tests for the stuff that is currently in main
. I should also look at packaging the whole thing up with distutils. The next post is going to be a long one, isn’t it?
Getting The Code
Although it’s still small enough to reasonably paste the code into this blog posting, I think it might be a little easier for folks to work with if they just had an archive of what’s been done so far. I’m going to start making it available directly from coolnamehere.
2015-03-28
Oh, that’s what that zipfile was for. No, it’s long gone now.
Backlinks
Added to vault 2024-01-15. Updated on 2024-01-26