Shop OBEX P1 Docs P2 Docs Learn Events
Python Server on OSX and Linux — Parallax Forums

Python Server on OSX and Linux

I'm writing up some quick instructions for running the Python Web server locally. I have Windows down, as that's what I have. But I'm not sure about OSX or Linux. I'd appreciate a double-check, for anyone out there who uses these OS's.

My instructions start after the Python binaries have been installed. These instructions are for Python 3.x.

For Mac, I tell users to click on the Spotlight search, type terminal, and double-click the Terminal app to run it. From there,

cd /path/to/files

to go to the directory containing the files to serve, and then

python -m http.server

For Linux, I know there are variations in the UIs in how to access the terminal. I can't do all the variations, so I'm just including a couple. Does the following sound right?

Choose Applications, Accessories, Terminal. ((The exact command structure may vary depending on the graphic interface you are using. For example, it may be Applications, System, Terminal on some interfaces.)

Then the same for cd'ing to the servable document root, and 'python -m http.server' to run the server.

I'm not sure if Mac and Linux need a fully qualified path to python. I'm not sure what the python installer does here.

Any help you folks can lend would be appreciated.




Comments

  • DavidZemonDavidZemon Posts: 2,973
    edited 2017-01-31 02:03
    I'm writing up some quick instructions for running the Python Web server locally. I have Windows down, as that's what I have. But I'm not sure about OSX or Linux. I'd appreciate a double-check, for anyone out there who uses these OS's.

    My instructions start after the Python binaries have been installed. These instructions are for Python 3.x.

    For Mac, I tell users to click on the Spotlight search, type terminal, and double-click the Terminal app to run it. From there,

    cd /path/to/files

    to go to the directory containing the files to serve, and then

    python -m http.server

    For Linux, I know there are variations in the UIs in how to access the terminal. I can't do all the variations, so I'm just including a couple. Does the following sound right?

    Choose Applications, Accessories, Terminal. ((The exact command structure may vary depending on the graphic interface you are using. For example, it may be Applications, System, Terminal on some interfaces.)

    Then the same for cd'ing to the servable document root, and 'python -m http.server' to run the server.

    I'm not sure if Mac and Linux need a fully qualified path to python. I'm not sure what the python installer does here.

    Any help you folks can lend would be appreciated.

    Linux sounds pretty accurate. The example you give (applications -> accessories -> terminal) sounds like Gnome 2, which is quite old at this point. Most newer Linux desktops (KDE being an exception I think... but I don't use it hardly ever) offer a searchable menu like Mac's Spotlight or Windows Vista+ start menu. If I search "terminal" in that menu, I get it popping right up.

    Python is indeed available on PATH by default, so no need to fully qualify the executable. It is installed to /usr/bin/python on most Linux installations.

    I've never run "python -m http.server" before... what does that do??? When I run it, I get:
    david@balrog:~$ python -m http.server
    Serving HTTP on 0.0.0.0 port 8000 ...
    
    
  • Gordon,

    Macs come with 2.n (most likely 2.6 or 2.7) versions of Python installed. You'll only need a fully qualified path if your Mac has multiple versions of Python installed (2.n & 3.x). Generally, if required by a specific project, Mac users install Python 3.x from MacPorts or Homebrew and can use a full path to exec their desired Python version.

    Here's a quick way to get an http server running on Mac OS X with Python 2.n :

    andyjamesdavies.com/blog/javascript/simple-http-server-on-mac-os-x-in-seconds

    For Python 3.x:

    https://github.com/processing/p5.js/wiki/Local-server

    Your Spotlight use for running Terminal is obviously aimed at new or UI-centric users. That's cool, but you could just tell them to look in Applications/Utilities for the Terminal app. Might as well get them used to using paths to their files as they will soon need that ability to to run Python scripts...

    dgately

  • Thanks for the excellent notes.

    For the Mac, would it be better to just have them use Python 2.x? The project doesn't need to have them running Python 3.

    For Linux UI distros, is there a somewhat "universal" name for the search feature?

    David, if you got that terminal response it meant python3 is running the http server that comes with that version. Do reasonably recent distros have either or both Python packages installed by default?
  • Heater.Heater. Posts: 21,230
    edited 2017-01-31 08:18
    The only search feature I know of comes with KDE (Nepomuk). Never used it. Used to be the first thing I disabled as it hogged all the CPU and disk bring the machine to a halt. Perhaps they have fixed that recently.

    There is always the "find" command.

    Debian Linux is still using Python 2 by default. As are distros I believe.
    $ python --version
    Python 2.7.9
    

    Every Linux distro I have used comes with Python installed by default.
  • TorTor Posts: 2,010
    What is it you intend to search for?
    There is a 'locate' command on most distros (although not all, by default). It runs a cron job at night to index files, so that 'locate <whatever>' is instant.
  • For the Mac, would it be better to just have them use Python 2.x? The project doesn't need to have them running Python 3

    That's really your call... Since 2.n versions are the default, sticking to Python 2 would be simple for less-technical users. Having to install MacPorts (or Homebrew) and learning its unique environment will no doubt put more steps in front of getting an http server up & running. Also, my own experience with installing Python 3.x versions has always been problematic as most of the scripts & modules in the open source world that I use, require version 2 of Python. Having a mixed set of version 2 & 3 scripts and modules in your environment is just more complex.

    The only issue is having different requirements in your instructions for Win versus Mac versus Linux (i.e. SimpleHTTPServer vs http.server, etc...).

    dgately
  • For Linux UI distros, is there a somewhat "universal" name for the search feature?

    Every Linux variant that I have used (probably not as many as a lot of folks, but more than most noobs) has a "System Tools" menu that includes LXTerminal, Xterm or an equivalent.

    dgately
  • Heater.Heater. Posts: 21,230
    edited 2017-02-01 17:15
    Hmm...I would have though a Javascript webserver under node.js would be easier. Easy to get installed and running on Linux and Mac. Fully supported by Microsoft on Windows.

    Heck, I even have a Linux shell and a Windows version of node.js on Windows 10 now. Provided by MS would you believe! Uses the MS chakra core JS engine.


  • Given 2.x in OSX and Linux, I'll change the Windows instructions to download 2.x rather than 3.x. I knew modern Linux distros had Python already, but wasn't sure if it was 2.x, 3.x, or a mix.

    Thanks for the replies. I think I have enough now to amend the quick start instructions I'm working on.
  • Heater.Heater. Posts: 21,230
    edited 2017-01-31 22:50
    I was thinking....

    May be it's better to write precise instructions for one Linux flavor, say Debian or Ubuntu, that are known to work. Not only that but specific to a current version.

    Rather than some hand waving generic instructions that may never work anywhere.

    There is nothing more annoying than finding some blog about how to install or do this and that, only to find that the blog is ten years old, using an unknown version of everything, and basically does not work any more.

    Edit: Actually what is annoying is that such blogs never state the date ate which they were written and more importantly never state the exact versions of the software packages involved. So then you are left in a limbo. Does this not work because I made a mistake? Or did something change in the mean time?



  • If you really need features from Python 3.x but want to stay with v2.x you could use the "__future__" module to use these features:

    Example:
    Division on Mac with Python 2.7.11 |Anaconda 2.5.0 (x86_64):

    Without the "__future__" module division is non-floating point
    >>> 5/4
    1
    

    With the "__future__" module, division returns a floating point value just like Py v3.0.
    >>> from __future__ import division
    >>> 5/4
    1.25
    

    But, then again you could use Python virtualenv and create separate spaces for Python 2.x and Python 3.x without messing with the build-in, or loaded, version of Python on the system.
    https://pypi.python.org/pypi/virtualenv
  • Heater, I used Ubuntu as the primary example.

    Jon, The only part of Python being used in this project is the HTTP server, so any 3.x-specific enhancements to coding language aren't critical. The instructions are aimed at raw beginners (starting a terminal), so anything requiring more elaborate features goes against the point of the exercise.

  • Heater.Heater. Posts: 21,230
    Ubuntu is a good choice. Instructions are quite likely to work on Debian and the Raspberry Pi with Raspbian. (Well, apart from the different Window managers...)

    I agree. Stick with Python 2 as that is what is in the box for those systems.
  • Jon, The only part of Python being used in this project is the HTTP server, so any 3.x-specific enhancements to coding language aren't critical. The instructions are aimed at raw beginners (starting a terminal), so anything requiring more elaborate features goes against the point of the exercise.

    I've seen both of these items mentioned in beginner Python courses, so I do not perceive them as advanced but rather useful. However, even the print statement is different between Python 2.x and 3.x although with the newer 2.x versions you can get away with the 3.x formatting but 3.x will not allow you to get away with some of the 2.x formatting.
  • Jon, Thanks again, but the instructions aren't for Python itself, just running its HTTP server. Other than the server (to avoid Chrome's cross origin violations when using certain features in local files), there's nothing about Python in this project, so the simpler the better.

    For another project, I'll be using Node.js on a Pi, with tons of JavaScript even, but that's for later this year. Yes, Heater will be proud of me!
  • Heater.Heater. Posts: 21,230
    edited 2017-02-03 05:29
    Gordon, I'm proud of you already. Raspi and Node. Great that you are even thinking about it.

    In theory the cross-origin thing is not just Chrome. All browsers should disallow it for security reasons.

    This can be bypassed by wrapping your web app as an application with Electron.js.

    But that is a whole other installation complication.


  • My current project (actually the one I finished that needed these instructions) worked around some of the CORS limits that raise Chrome's ire simply by choosing something else. There were alternatives to Web Audio API, for example, or interacting with the canvas, that worked just as well for my application. So I was still able to do what I needed with local files only, and still not resort to Firefox, or running Chrome with the local files flag. (This was a for learning to code book.)

    The Node.js project can't avoid these things, though, and needs xmlhttprequest and other things, so a server-we-shall-go. This project will be a robot with a fully interactive video and graphical interface built, of course, on nothing but JavaScript.
  • Heater.Heater. Posts: 21,230
    edited 2017-02-03 13:57
    Sounds cool.

    I like to use web sockets for streaming data from server to browser. Made dead easy by using socket.io http://socket.io/. Three.js is my graphics engine of choice, nice GPU accelerated webgl in an easy to use API. Like this experimental visualization here. http://devserv.rsmtech.fi/

    Sounds like you should give Electron a look. Basically you end up with a node.js process that runs the Chrome renderer, plus whatever JS is in your web page, in another process. Then the JS in the page has use of the node.js API and can use all node modules. Free range access to your machine. No server required. All qrapped up as an application.

    Unless you really want to use the GUI remotely from the server over the net as usual.

    No need to think about it much now. It should be easy to get your server and client code into Electron after its all developed.

    Now, how to get JS running on the P2?
  • Electron is nice, and I keep thinking of ways to use it, but this is an education project rather than an end product. Folks will build this up by components, following a set of lessons that add pieces as they build. They're certainly free to wrap it for their own final application. I might do an appendix that discusses Electron.

    The project needs a real-time controller for the robotic functions, so it might as well as well run the Web server as well. It's certainly not the only way to do it. A cheap tablet serves as the human interface.

    I haven't decided on a graphics engine, but the entry-level chapters won't use any. Just straight-up JavaScript, CSS, and HTML5. Much of the project is about teaching these as generic skills. I don't even plan on using jQuery unless I absolutely have to. Not that I dislike jQuery, but for first-learners I'd rather not muddle the discussion with yet another layer of abstraction.
  • Heater.Heater. Posts: 21,230
    I totally concur with the no jQuery or other library for the beginner.

    The best Javascript framework is Vanilla.js: http://vanilla-js.com

  • Yeah, I love Vanilla. All the things it can do, using code you're already familiar with.
Sign In or Register to comment.