Starting Out (and pulling my hair out) with Flask

Recently I started learning the Flask web framework.  Mostly because I have been doing a bunch of Python coding and would like that to bleed over a bit into the web development arena.  The need is not really out of anything work-related, its more of a personal project need.

I can say, though, that getting apache and Flask operating together has certainly added a few grey hairs to my head, mostly in frustration.  There are plenty of resources ( if you search the Googles) for setting up Apache web server and Flask, to work together.  But I have to say that, as great as the resources that are out there, are, there are a few (pertinent) details that were left out of most of them that I will now cover.

First, working in a Virtual Environment does not have all of the same settings as not working in one.  If you look at this link, you will see (near the bottom of the document) that there are a couple of things you have to set in your .wsgi file, to specify the load paths for your virtual environment. 
NOTE: It is important to note that that link is the same root site for the Flask link above.  So they definitely have a lot of documentation on their product.

Now, while the above is important, it didn't solve my issue, which is that on a machine remote to where I am running my Flask app and web server, I was not able to go to http://:5000 (the port Flask runs on) and see the page displayed as expected.  Instead I received a typical error page stating that the page could not be loaded.  This got even more frustrating with each new thing that I tried or modified to get it working.  No matter how seemingly possible of a fix, it didn't work.  Until.....

I found a StackOverflow thread about running a Flask app under the Apache web server.  I read the person's question and went through their code (seeing all the similarities) and there it was... a setting that no other site had mentioned.  Not even the video tutorial I was going through.  It was part of my Flask app's __init__.py file and the part in question looks like this:

app.debug = True
app.run(host='0.0.0.0')

The first line is inconsequential and just turns on debug mode.  The second line was 1/2 different from mine, but crucially different.  I had the app.run() that all the tutorial's had mentioned, but I did not have the host='0.0.0.0' portion.  I put it in, started up Flask (by running the __init__.py file) and VOILA!!!  I had the output that I expected to see in my browser. 

Needless to say, it was certainly a learning experience ( as I now have plenty of notes for running a Flask app with Apache).  Now I can get on with my learning of the Framework since the tedious job of getting the web page serving is now out of the way.  Yay!

Python pip Broken After Upgrade To OSx El Capitan

Wow its been a long time since I blogged.  I have no excuse other than things have been a touch crazy.  My work recently started allowing us to upgrade our Mac's from Yosemite to El Capitan.  For me the upgrade only took about 45 minutes, which is pretty quick in the grand scheme of things.  The download is a little over 6 gb and went pretty quickly.  

I was going along fine until today when I tried to install a new module using pip.  About 1/2 way through the installation I was presented with the following output:

    In file included from src/lxml/lxml.etree.c:321:
    src/lxml/includes/etree_defs.h:14:10: fatal error: 'libxml/xmlversion.h' file not found
    #include "libxml/xmlversion.h"
             ^
    1 error generated.
    Compile failed: command 'cc' failed with exit status 1
    creating tmp
    cc -I/usr/include/libxml2 -I/usr/include/libxml2 -c /tmp/xmlXPathInitf3OxN6.c -o tmp/xmlXPathInitf3OxN6.o
    /tmp/xmlXPathInitf3OxN6.c:1:10: fatal error: 'libxml/xpath.h' file not found
    #include "libxml/xpath.h"
             ^
    1 error generated.
    *********************************************************************************
    Could not find function xmlCheckVersion in library libxml2. Is libxml2 installed?
    Perhaps try: xcode-select --install
    *********************************************************************************
    error: command 'cc' failed with exit status 1
    ----------------------------------------
Command "/usr/bin/python -u -c "import setuptools, tokenize;__file__='/private/tmp/pip-build-9IduXA/lxml/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-RgavmY-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /private/tmp/pip-build-9IduXA/lxml/

I had installed other modules last week, but then I realized that that was prior to my upgrading.  I looked at the above output and noticed the line:

     Perhaps try: xcode-select --install

OF COURSE!!!  Although I upgraded, and XCode had been upgraded to, I still needed to do some things with XCode to get things going again.  First, I opened XCode and went through its initial startup after an upgrade.  A bunch of clicking and things were good there.  I then opened up my command line and, prefixing the command with 'sudo', I ran the 'xcode-select --install' command from above.  This presented me a pop-up window to install tools.  So, I accepted and allowed it to install.  Once finished, I tried my pip module installation again and VOILA!!!!  It worked!!!

So, in this lesson, always make sure to update your XCode and xcode-select before moving on after an upgrade.

Homebrew and the Untracked Working Tree Files

On the Mac, you have package managers that are designed to allow you to install software via the command line.  Two of the majors are MacPorts and Homebrew.  This is specific to Homebrew as that is the one that I chose to use for my system.

If you are like me, you install the software you need and then don't touch Homebrew for a while.  During the lapse in use, the system tends to get stale and you will find that before you search for software or are able to install anything, that you must  first update it.

The update is usually simple and run as follows:

sudo brew update

Unfortunately, its not a perfect system, and will let you know this by pretty much bitching and complaining and exiting, refusing to update.  The output of such a hissy fit looks similar to this:

> sudo brew update --force
error: The following untracked working tree files would be overwritten by checkout:
Library/Aliases/fishfish
Library/Aliases/fluidsynth
Library/Aliases/gearmand
Library/Aliases/git-tig
Library/Aliases/gnu-scientific-library
Library/Aliases/google-go
Library/Aliases/gperftools
Library/Aliases/gpg
Library/Aliases/gpg2
Library/Contributions/brew_bash_completion.sh
Library/Contributions/brew_fish_completion.fish
Library/Contributions/brew_zsh_completion.zsh
Library/Contributions/cmd/brew-aspell-dictionaries.rb
Library/Contributions/cmd/brew-beer.rb
Library/Contributions/cmd/brew-bundle.rb
Library/Contributions/cmd/brew-cleanup-installed
Library/Contributions/cmd/brew-dirty.rb
Library/Contributions/cmd/brew-gist-logs.rb
Library/Contributions/cmd/brew-graph
Library/Contributions/cmd/brew-grep
Library/Contributions/cmd/brew-leaves.rb
Library/Contributions/cmd/brew-ls-taps.rb
Library/Contributions/cmd/brew-man
Library/Contributions/cmd/brew-mirror-check.rb
Library/Contributions/cmd/brew-profile.rb
Library/Contributions/cmd/brew-pull.rb
Library/Contributions/cmd/brew-readall.rb
Library/Contributions/cmd/brew-server
Library/Contributions/cmd/brew-services.rb
Library/Contributions/cmd/brew-switch.rb
Library/Contributions/cmd/brew-tap-readme.rb
Library/Contributions/cmd/brew-test-bot.rb
Library/Contributions/cmd/brew-tests.rb
Library/Contributions/cmd/brew-unpack.rb
Library/Contributions/cmd/brew-which.rb
Library/Contributions/cmd/git
Library/Contributions/cmd/public/bootstrap.min.css
Library/Contributions/cmd/public/glyphicons-halflings-white.png
Library/Contributions/cmd/public/glyphicons-halflings.png
Library/Contributions/cmd/svn
Library/Contributions/example-formula.rb
Library/Cont

No matter what you do with the brew command (at least from what I have found), you won't be able to update.  What is nice though, is that brew uses git to do its checkouts and updates.  And, for your knowledge going forward, brew uses /usr/local as its base directory.  So, the easiest way that I found to correct this issue and update brew is to completely bypass the command and go straight to git.  

The following set of commands should work to get your brew back up and working(note, I am sudo running these commands):

# cd /usr/local
# git fetch origin
# git reset --hard origin/master

After doing the above, you should find that running brew update has the following results:

# brew update
Already up-to-date. 

Why?  Because you just circumvented the brew command and updated it manually.  You can now run 'brew search ' or whatever other brew command you were going to run.  Have fun!

The [sometimes] trouble with updates

No, I am not referring to Windows updates. Instead, I am referring to Linux updates. There are mixed views on whether you should do updates or not on your system(s). Here is my view.... if it is a server, update it ONLY when you are absolutely needing to. This means only if there is a security hole that is fixed by a newer version. On the other hand, if it is a desktop system, if you update then it is up to you.

If you do updates though, you really need to watch out. Make sure you know what exactly is happening during the update(s) as things tend to change and also stop working.

I did an update earlier this evening after booting up my laptop. No worries, right? Wrong. When I tried to start my apache web server (which was previously installed and working fine), I discovered that it was no longer working. Strange if you ask me, but it wasn't starting up. It kept giving me the same errors:

# /etc/init.d/apache2 start
* Starting web server apache2 [Fri Oct 24 22:15:10 2008] [warn] module php5_module is already loaded, skipping
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

I started by plugging in the different errors into Google, but kept going in directions I didn't think were the answer. Then I looked at the last error: "Unable to open logs". That was odd because I hadn't changed anything, but...... then there was the updates.

So I checked and the /var/log/apache2 directory and saw that it was owned by root and had a group of adm. I distinctly remember that being the group root the other day. So, instead of changing permissions (which is someting I was not wanting to do, I decided to add root to the adm group.

I restarted apache and VOILA!!! Problem fixed. So, the lesson.... know what updates are being applied and if something doesn't work afterwards, you will at least know why.