Python — develop, sell, deploy, protect Nov 2022

Objective: develop software for one’s own use

Potential Requirements:

• • fitness for the purpose (practicality, accuracy of results, ease of use)
  • ease of development and maintenance

Unnecessary requirements:

• • deployability
  • strong security
  • conventional methods
  • conventional language
  • conventional processors/machines

A common example

Objective: develop saleable software for use by others

Potential Requirements:

• 1. fitness for the purpose (practicality, accuracy of results, ease of use)
  2. easily deployed
  3. (*) security
  4. (*) protection from piracy
  5. (*) protection from unauthorized modifications
  6. (*) payment method
  7. (*) marketing method
  8. (**) protection from obsolescence ∴ conventional language, et cetera
  9. ease of maintenance ∴ conventional language
  10. acceptance ∴ conventional processors/machines

• The items marked (*) take a large toll. The developer must now set up a payment method, and a marketing method. But that is doable; let’s check off items (6) and (7).

Next let’s ask, “Can we use Python?” Clearly, the answer is no because there is no conventional way to deploy it and protect it from piracy:

• • Item (3) might be achieved specifically within the program.
  • Items (4) and (5) would not be achievable.
    The very reason Python would be chosen is the Python ecosystem.
    But Python programs are not compiled.
    Therefore, the ecosystem must be installed on the user’s machine
    Therefore, items (4) and (5) would not be achievable.

Next let’s ask, “Will we achieve security using Python?” Clearly, the answer is no, again because of the ecosystem.

• • Item (3) would not be generally achievable.
    All of the ecosystem must be installed on the user’s machine(s).
    Therefore, someone within the user organization must be designated to install and maintain the ecosystem
    Therefore, little or no security in the broad sense.

Next let’s ask, “Will we be able to protect against obsolescence — even in the short term?”

Item (8) requires careful consideration of the dependencies of our software.

This means, of course, the standard ecosystem, and any third-party packages used by our software. It is easy to recall numerous businesses that have fallen out of existence. Maybe worse, the business doesn’t go out of existence but a key product line is dropped or severely overhauled. If our software was based on such businesses or product lines, we would have to establish a replacement arrangement, if one exists.

Imagine we are aware of all that above, yet we must optimistically proceed toward a compromise approach to a specific software solution. Let’s call it ‘Software X‘.

After selling Software X to a client company for in-house installation:

• the company must have a designated ‘keeper’ for the Python environment
• the keeper would install and maintain all necessary Python environments for all users
• the keeper would be available for all Python questions
• the keeper would be available for all Software X questions

I would say most companies are not quite ready for any of the above. Those most competent in IT, are busy with other assignments and duties. Those less competent may not have the ability or the desire to become competent in Python, et cetera. An employee might step up to the challenge and stay with it for a while. If Software X is worth buying, and if it is valuable to employees, then the support system must have continuity over at least a few years.

Seems to me there is little chance of this working out for most companies.

Let’s, again, imagine we are aware of all that is said above and yet we optimistically proceed toward a compromise approach to a specific software solution. Again, let’s call it ‘Software X‘.

After selling Software X to a client company for use online, certain requirements go away:

• the company must have a designated ‘keeper’ for the Python environment
• the keeper would install and maintain all necessary Python environments for all users
• the keeper would be available for all Python questions
• the keeper would be available for all Software X questions

For the client company, the arrangement seems more tenable.

For the developer, the situation likely improves. The developer maintains a Python ecosystem in the cloud. The Python programs are executed in the cloud — behind a web framework such as Flask.

Certainly, security should be questioned here as for any web app. How secure is Software X from piracy or from unauthorized modification?

Deployment becomes easier. Pay-per-use is now possible. The app may be used from a Mac or Windows or Linux.

Question: So what is the downside of an online app?

Answer: No interaction with:

• other programs
• other online apps
• customizable solutions

These downsides are not insignificant. By making Software X more saleable and, in some ways, more useable — it becomes more fragmented!

The idea of a third-party package is that it works somewhat seamlessly with other packages especially if it is programmable.

When we consider data and calculations using that data, we expect data flow with relatively neat input and relatively straightforward output.

A detached online app does not satisfy that expectation.

Link

https://www.datarevenue.com/en-blog/data-dashboarding-streamlit-vs-dash-vs-shiny-vs-voila#:~:text=Dash%20is%20a%20data%20dashboarding,to%20build%20a%20data%20dashboard.

Excerpt

Dash vs. Flask

Dash is built on top of Flask and uses Flask as its web routing component, so it’s not very meaningful to compare them head-to-head. Dash is a data dashboarding tool, while Flask is a minimalist, generic web framework. Flask has no data analytics tools included, although it can work with other Python libraries that do analytics.

• • use Dash if you want to build a data dashboard
  • use Flask if you want to build a far more generic web application and choose every component in it.

In 2020, I built a couple of apps using Dash.

I note that the apps are:

• • certainly not complex applications
  • certainly not connected to other software

However, the apps efficiently solve important problems in structural engineering.

Coefficient C for Bolt Groups
https://khoitsma1.pythonanywhere.com/apps/app5
Replaces 48 pages in AISC 15th Manual

WT Strut Capacity (eccentrically loaded)
https://khoitsma1.pythonanywhere.com/apps/app6
I transformed my WT strut spreadsheet into a single program function with only 8 inputs.

def WTStrutEcc(sh_name, stl_name, P_load, Lb_feet, Gusset_thickness,
               Stem_in_CompressionQ, Axial_amplificationQ,
               Consider_selfweightQ):

Two databases are used; one for shape properties, and one for steel properties.

Notice the optional plot.

I’m not a professional developer.

I am a structural engineer with a strong math and computer background, I have programmed in Python for about 10 years. I built Excel applications using VBA starting in 1993. I have used PyXLL for 9 years. I have used Pythonista for about 4 years.

Conclusions

Despite remarkable advances across the spectrum of the desktop, the devices, and the web …

… a quandary remains.

How best to have programs and their data interact?

I have defined my concerns as of 2022. I suppose many of us are, as I am, looking for a solid solution to developing software that:

• interacts with other software
• is easily maintained
• is secure
• is protected from piracy
• is saleable

Happy to hear from those with suggestions or comments.

Karl Hoitsma

There are a couple more things that make Python a drag.

• user interface
  • several options
  • none are slick
    • Tkinter (dated)
    • Kivy (??)
    • PyQtX (seems dated)
    • PySide2 (good, tedious)
    • PySimpleGUI (simple, works within Jupyter!, active development in 2022)
• graphics
  • a bajillion plotting solutions
  • many of them are great, Plotly is a wonderful plot tool
  • none of the good ones have fully generic graphics primitives
    • with composable points, lines, curves, text
    • on the plot
    • off the plot
    • no plot (blank page)