[Python] Customer Base?

[Leitz]

The python code we're writing is useful to others. We've all seen cases where coders code but don't take users into account. The software ends up pristine since no one but the coders ever touched it.

Who would our "user" be for python based software? Here are some guesses on the assumption we are representative of the user base. Please expand.

Things about us:

• Able to install Python.
• 50/50 chance of Python 2 or 3.
• 60/40 Windows / Linux. Mac?

Things that might be useful to know:

• Prefer Web, GUI, or CLI interface?
• Willing to install non-stdlib modules (MongoDB, etc)?
• Wants to share generated data with other users?

Thoughts? Do we even want to consider the effort it would take to make this usable by a non-coder?

 

[simonh]

This is why StarBase is packages as a Windows executable. This is dead easy, even for a big complex app like StarBase the py2exe config is just a dozen lines or so. Users shouldn't need to have to be concerned about installing a development environment.

The tricky part is building a good interface, be it command line, GUI or web. It's also how to add value with useful features. That's why StarBase has tools for transforming world data, creating and editing network links and exporting maps and data in different formats.

Personally I'm more familiar with GUI development, but I have written a few Flask apps for work so web dev so not completely alien to me. I've also played around a bit with Google App Engine.

Simon Hibbs

 

[robject]

I would be a user of that Python code. As a programmer but unskilled in Python, I'd love to have Traveller libraries I can pull in and use in the process of building useful Python Traveller programs.

Assuming Python 3 is truly an improvement over Py2, I'd use that.

I use both Windows and OSX... well and some Linux too (RPi).

 

[Leitz]

I would be a user of that Python code. As a programmer but unskilled in Python, I'd love to have Traveller libraries I can pull in and use in the process of learning Python and (of course) building useful programs.

Assuming Python 3 is truly an improvement over Py2, I'd use that.

I use both Windows and OSX... well and some Linux too (RPi).

The jury is still out on whether or not Py3 is an improvement. So far the Dev Team seems happy with both Py 2 and Py 3. Likely we'll continue to code for both.

Of course, this means we expect you to tell us when things blow up or don't make sense. How does it feel to be an Alpha tester?

 

[ShawnDriscoll]

The python code we're writing is useful to others. We've all seen cases where coders code but don't take users into account. The software ends up pristine since no one but the coders ever touched it.

Who would our "user" be for python based software? Here are some guesses on the assumption we are representative of the user base. Please expand.

Things about us:

• Able to install Python.
• 50/50 chance of Python 2 or 3.
• 60/40 Windows / Linux. Mac?

Things that might be useful to know:

• Prefer Web, GUI, or CLI interface?
• Willing to install non-stdlib modules (MongoDB, etc)?
• Wants to share generated data with other users?

Thoughts? Do we even want to consider the effort it would take to make this usable by a non-coder?

The GitHub should also contain a ZIP of the executable and folders it might need to run. No one is going to have the same Python setup as I. And the EXE at least shows what the program does out of the box, for those interested in maybe learning Python and later downloading the source to play with.

 

[Leitz]

When I was bouncing the "portability" question in my head Golang seemed to be a useful option. it uses executables but the same source can be compiled for Mac, Linux, and Winders.

The other portable option is web based, but that limits to actual programs like world or character generation. The libraries are probably by definition "portable" since they would only be used by developers, right?

And I just read about the PyPI issue. ugh!

 

[simonh]

Python is just as cross-platform as Go. Any of the open source languages should work fine on any of the major platforms.

The real issue for portability isn't the core language though, it's the GUI framework you use with it. I'm not sure what options there are for Go as it's still a fairly new language and mainly aimed at systems programming rather than applications. I tried to end-run around platform GUI support by using bindings for Qt, but while that works fine for Windows and Linux I've found it practically impossible to get working on OSX. I might have to consider putting it in a WINE bottle.

Simon Hibbs

 

[whartung]

The only way I would probably look at this code is if I were rewriting it and came across some puzzling bit of workflow in the process and curious how others sussed it out. Never say never, but I'd never code in python myself.

 

[Leitz]

Python is just as cross-platform as Go.

Not really seeing that, can you explain? I can write and compile a Go program and just give out the binary. With python, unless the py2exe works for Mac and Linux, it means the libraries and stuff have to be installed.

 

[simonh]

Not really seeing that, can you explain? I can write and compile a Go program and just give out the binary. With python, unless the py2exe works for Mac and Linux, it means the libraries and stuff have to be installed.

It’s not all that hard to manually package up a Python (or Ruby, etc) install with your own scripts, plenty of professional apps do this. But cx_freeze makes it pretty simple and works on Linux, Windows and Mac, it’s basically a cross-platform py2exe but I learned Py2exe first and its a bit simpler if you’re just working with Windows.

I looked at cx_freeze when I was hoping to support OS X but since that never panned out I stuck with Py2exe.

Simon Hibbs

 

[ShawnDriscoll]

As a hobbyist, I can't get excited about Golang. It's more on the functional side of programming. And it's a compiled language.

I didn't hear anything about PyPI recently. But then I store my code on Google Docs or on GitHub, because legacy code.

 

[simonh]

There was a fuss about packages containing malware that had been uploaded to PyPI recently. If you included them in your project you could infect your user’s computers.

Simon Hibbs

 

[Leitz]

In the article it says PyPI packages have been inserted where there are name errors possible. Like "urllib" and "urlib". A German college student had thousands of downloads for his altered packages.

simonh's comments may resolve the portability issue, something to look at. That was what I looked at Golang for. Well, that and coolness.

 

[egor045]

The python code we're writing is useful to others. We've all seen cases where coders code but don't take users into account. The software ends up pristine since no one but the coders ever touched it.

Who would our "user" be for python based software? Here are some guesses on the assumption we are representative of the user base. Please expand.

Things about us:

• Able to install Python.
• 50/50 chance of Python 2 or 3.
• 60/40 Windows / Linux. Mac?

Things that might be useful to know:

• Prefer Web, GUI, or CLI interface?
• Willing to install non-stdlib modules (MongoDB, etc)?
• Wants to share generated data with other users?

Thoughts? Do we even want to consider the effort it would take to make this usable by a non-coder?

Looking at my code, I think the likely user is a coder with some Python exposure who can get to grips with Github ("code by developers, for developers"). I'm a little disappointed with myself It would, I think, be good to extend the potential user base. We're producing some useful libraries and it'd be good to have the work be of benefit to a larger non-coder population.

One of the advantages of what we're doing at the moment is having a set of libraries that others can build upon - I'd be delighted if something I developed ends up in an easy-to-use shiny application (mostly because writing that shiny application requires skills and experience that I don't have).

That said, I'd like to do more than just provide libraries. My preference is either for CLI tools (comes of being a Unix greybeard) or web UI, mostly because I have zero experience or expertise in UI development. I can just about cough up a simple web UI in Flask, or an ugly CLI script with lots of inscrutable options. In the longer term, I hope to be able to stick some form of web UI in front of my code and deploy to an AWS micro instance or Heroku or somewhere similar. The UI and deployment code would be on Github so anyone interested could do the same.

 

[robject]

There's something to be said for a REST API; it could power both a CLI and any sort of UI written in anything (like the current fad-of-the-month JavaScript-related framework on the browser, or just a humble Java Swing app).

 

[ShawnDriscoll]

Had to look up what REST was. Went down a rabbit hole and found nothing. Apparently, it gets used by all kinds of apps these days whether intentional or not.

 

[aramis]

Things about us:

• Able to install Python.

Thoughts? Do we even want to consider the effort it would take to make this usable by a non-coder?

There is a bundler that allows standalone python apps for mac; no native py install needed. I don't know if it was upgraded for current versions. I last played with it more than 5 years ago. IIRC, it was Py2App, and appears to still be out there.

I read of a similar one for 'doze...

 

[simonh]

Had to look up what REST was. Went down a rabbit hole and found nothing. Apparently, it gets used by all kinds of apps these days whether intentional or not.

It's a kind of 'back to basics' approach to web APIs where you use the primitive HTTP operations such as GET, POST, PUT, etc to directly manipulate resources, which are exposed via a hierarchical URL structure. So in REST to change the UWP of a world in the Glisten subsector you'd do a POST operation of the UWP string (or a SEC file line, or a JSON file of the data) to...

http:\\www.traveller_webapp.com\sector_data\Spinward_Marches\Glisten\0411

So in REST the information about what record you are updating or accessing is in the URL and only the data is in the payload. This means you can explore REST APIs and their data using an ordinary web browser.

It's an alternative to message based web APIs like SOAP where you send a message blob, or document, which contains all the actual instructions about the operations you want to perform and then the application sends back a message blob back with the response. The resource structure and the operations you can perform on it are completely hidden at the HTTP level. In that sort of system you'd POST maybe an XML document to the single URL endpoint of the app, and in the XML document it would contains fields saying this is a world update, which world is being updated and what the world data is.

Simon Hibbs

 

[joshualevy]

In addition to what Simon Hibbs said, I'd add:

REST interfaces are "stateless" meaning that everything needed by the server to reply to that request is in the request itself. (I'm over simplifying a little bit.) From a practical point of view, this makes REST interfaces much easier to troubleshoot, to understand, and to test. Since REST interfaces are easier to troubleshoot and test, they tend to have fewer bugs and that means the servers are better. Since they are easier to understand, they are easier to use, so there are fewer bugs in the client.

Also (while this may not matter to us) it's much easier to "scale" servers that are based on REST interfaces. In your class SOAP interface (or other interfaces) they often work well as long as all requests are handled by one computer server. But these interfaces often have bugs, often very hard to find bugs, when you need to have more than one server to handle the load. REST interfaces are generally much easier to run on multiple servers.

And yes, I have been responsible for running REST servers, SOAP servers, and other types of servers. I can tell you from personal experience that because REST servers are easier to test they are much more solid that other types of servers. Same with ease of troubleshooting; makes for less downtime.

Joshua Levy

 

[giant.robot]

In addition to what Simon Hibbs said, I'd add:

REST interfaces are "stateless" meaning that everything needed by the server to reply to that request is in the request itself. (I'm over simplifying a little bit.) From a practical point of view, this makes REST interfaces much easier to troubleshoot, to understand, and to test. Since REST interfaces are easier to troubleshoot and test, they tend to have fewer bugs and that means the servers are better. Since they are easier to understand, they are easier to use, so there are fewer bugs in the client.

Also (while this may not matter to us) it's much easier to "scale" servers that are based on REST interfaces. In your class SOAP interface (or other interfaces) they often work well as long as all requests are handled by one computer server. But these interfaces often have bugs, often very hard to find bugs, when you need to have more than one server to handle the load. REST interfaces are generally much easier to run on multiple servers.

And yes, I have been responsible for running REST servers, SOAP servers, and other types of servers. I can tell you from personal experience that because REST servers are easier to test they are much more solid that other types of servers. Same with ease of troubleshooting; makes for less downtime.

Joshua Levy

A small addition to this explanation is the HTTP method (GET, POST, etc) tells you the exact type of operation you’re performing and should set your expectation of mutability and idempotency. If you do a GET request a million times to the same resource, it should never change it (idempotent). The HTTP response code should also be informative about the operation so simply requesting the header for a URL can give the client useful information about the state on the server. It’s much closer to the original read/write conception of the
Web than other web service interfaces.


To the larger point of Python versus whatever, a nice reusable module with pydoc strings and some sort of default behavior if called directly let’s end users do what they please. The front end gets to be decided by an end user. That being said the Tk GUI toolkit is often distributed alongside Python installs. OSX ships with Tk 8.5.9 IIRC and many Linux distros also ship TCL/Tk out of the box as well. On Windows you’d likely distribute via py2exe so it’s immaterial.

So that end blog post describes packaging a Python app for OSX with py2app and also has helpful links to other Python packagers like PyInstaller and py2exe. Those distribution methods make it easier to bundle a GUI library with the app.

Using a language like Go would likely end up with more problems as the pool of contributors is smaller and the tooling and packaging for non-Unix systems is not very mature or robust. The cross section of people with adequate Go experience, experience with writing cross-platform GUI apps in Go, and people wanting and willing to work on Traveller apps is likely to be minuscule.

Just some thoughts from the peanut gallery.