Building: No need with python?

Yes, building is needed with python.  Python normally uses an environment build approach which allows the developer to run code without noticing a build, and simple programs even when shared can seem to need no build.  To get started with programming with python, you just don’t notice builds, although usually they become important later.  But with Kotlin, builds are there from the outset.  This page provides background on building, both with python and kotlin.

The good part of building in python, is building as you develop is so simple you don’t really notice.  The negative is if you later want to package up what you have developed, you may be confronted with one of a wide range of different builds options some of which can be quite complex.  Kotlin is in the middle. More work for the simplest program, but more robust builds for large systems.

Building Introduction Topics:

• What is Building?
• The Two Ways to Build: Environment vs Package Build
  1. Environment Build
  2. Package Build
• Building in Python
• Building in Kotlin
• Conclusion: The different focus of Python and Kotlin

What is Building?

A Definition: Building is the process of putting in place all the components needed for a program, and providing the code with location information(where is it?)  for each component.

The components are the resources needed by the program, such as program code for library functions, and images that may be used by the program. In the simplest “hello world” program needs a library function in order for the print to happen. How does the code written in “hello world” get to access the “print” function?

Developing in python, it can seem like there is no such step as ‘building’.    The reality is that python uses  an environment build approach, and during development any new libraries or other resources are added to the environment. Hello world runs can print because the program only runs on a computer with all of the python standard libraries installed on that computer, and in a location such that any python program can find them.

Other libraries get added to the computer environment as the developer needs them. So the steps to prepare the environment happen over time and can be forgotten. It is only when there is a need to run the program on computer other than the development computer, and all the environment install steps need to be repeated, that the environment build gets noticed.

Note also, that reliance on this approach is central to how Python is at its best when the Python program will be run by either the original programmer or another programmer, but Python can be limited or more difficult in creating programs to be run by end users.

Sometimes asking anyone who runs the Python program to:

• first install python on your computer, and make sure you have python verison ?
• now add this list of packages to your computer, each with the correct version
• now you can run the program i just gave you

is just too much to ask.

Packaging the program together with the correct version of python itself, and all relevant libraries is a better solution, but that requires a package build and getting them right can be complex.  But to run your own program, particularly if it is a simple one, the environment build approach means the build goes unnoticed.  I mean, you had to install python to write the program, no?

The Two Ways to Build

Environment Build vs Package Build = Install vs Dependency

An environment build is where all the resources needed for the program are installed in the environment prior to running the program, enabling different programs to share the same resources.

By contrast, package build is where the resources for the program are packaged inside the program file, ensuring each program is self contained and independent.

1. Environment Build.

For an environment build, it the environment around the program that is built. An environment build means running the program on a new computer will require an ‘install’. The install can either be a series of steps to be followed manually, or there can be an install program to perform those steps.

The advantages of environment build are:

• no need to re-install resources that have been previously installed into the environment in order to run previous program(s)
• during development, each new resource can be installed as required and independently, resulting in only one build during the entire development cycle

Disadvantages of environment build:

• distribution of the application requires either a manual install process, or building of an installer with a package build which can be an significant additional development step
• different applications may want different versions of resources to be present in the environment which may cause complex conflicts that are difficult to identify and/or resolve.  The result can mean getting an application to run on a different computer is a nightmare
• the target environment may not support complete python libraries, blocking even the simplest hello world python app from a computer such as an Arduino or other embedded application

 2. Package Build

A package build is where the components are combined in a single runnable ‘package’ file containing the components required by the program.

Advantages of package build:

• distribution of the application can be as simple as just one file
• each application contains its own components so no version conflicts can occur
• the application can be packaged with just the components required, not entire libraries

java.jar files, windows.exe, android.apk files, MacOS.app files, Linux.so files and iOS.ipa files all use a pure package build approach, which does require a build before every run, but means a fully portable self contained program is readily available for a given platform.

Building in Python

Building in python is very different for different uses of python.

Developer is the end user: One of the most common situations with python is the SEAAS developer, who is both the developer of the program and the end user of program. The resources needed by the program are installed as the program is built so there never seems to be a build at all.

Building for python.py files mostly becomes installing python, then ensuring all the imports have all the packages those imports require installed. If the imports all work, the environment for the python.py program has been built.  Once the environment is built, the program can easily be run without further steps.  The disadvantage of the this ‘build the environment’ approach is that for each new version of python the environment to satisfy the all python programs must be rebuilt, or alternatively a virtual environment approach must be adopted for development, and deployment can be problematic.

Web Server: Even if a web server is viewed by millions of people, the application only needs to be installed once per server, and it can be installed by the developer or other very skilled people.  Manual install of the environment for the python code, even if there are several steps, is entirely practical and is done by the developer.

Mobile Applications: Kivy is probably the best mobile framework for python, but like any other mobile app, Kivy apps, like all mobile apps, must be fully packaged.  Building a packaging is not part of standard python workflow, so the specifics of packaging kivy must be learnt and is quite is a complex and often fragile process.

Sharing with other friend/colleague Python Programmers (SEAAS): Simply send the source file, the other programmer probably already has python (probably the right version?) installed.

With simple python programs, there are no other ‘parts’, just python itself and just the one file.  As programs grow, there are imports, and then libraries to install to enable more imports. If the person installing knows pip install, they will quickly satisfy other requirements.  No build by the developer, manual environment build by the end user that is quite straightforward provided the end user can develop in python.

Sharing libraries and/or applications on PyPI: PyPI (or the “cheeseshop”) allows sharing open source python projects ready for simple installation into any computers python environment with a simple ‘pip install’.

Windows / MacOS applications: To distribute an application, to be installed and run by someone who need not know how to program in python, there are a variety of solutions. py2exe and pyinstaller and examples, and in each case the process is equivalent to a build that automates the install for regular users of the program.

Building in Kotlin

The bad new: There is always a build process.

The good news: There are build processes that work for all scenarios and are highly refined.

First, on that bad news.  Even the kotlin “hello world” program needs a build.  The ‘hello world’ program must call a print function, that has to be connected with the program code.  With python, the print function is in the standard library, which was installed in the python environment when python was installed so the developer needs no further build, unless that developer wants to send the program to a friend as a “helloexe” type file……. which would of course need a build.  However for “hello world” , having a “hello.exe” is not needed so you do not notice.

With kotlin, you are going to get the equivalent of “hello.exe”, so you there will be a build. The “hello” code must be built into a file together with the “print” function to be a complete program, and that requires a build.  All kotlin programs are made ready for installation on a computer, without first installing kotlin on any computer which will run the program.  Either as the “hello.exe” with kotlin native, “hello.jar” with the java version or “hello.js” to run in a browser.  Kotlin offers that choice (a level of choice not matched by python) but always requires a build.

Secondly, on the good news: The build is very simple. Because every developer is doing builds all the time, building is highly evolved.  Building can seem complex, because it is very flexible, and to learn all that can be done with build is still huge.  But to learn simple builds, equivalent to the examples for python given above is very easy.  The trap to avoid is the trap of trying to learn all that can be done with builds before getting started.

Conclusion: The different focus of Kotlin and Python.

Note: What applies here for python, also applies for many other ‘dynamic’ languages.

For someone writing programs for their own use, or for their colleagues who can also program in python, or for Web Servers where programmers start the web server program,  python provides a virtually ‘build free’ development cycle. Building can be virtually ignored.

With Web servers, where millions can use the site built in Python and installed on just the one web server system, python also provides a close to a build free experience, enabling the advantages of no build even for use by those who program as a profession, since the end users make use of the running program on the server, but end users do not start the program.

For applications or mobile apps to be distributed for the mass market, and particularly apps/application by professionals to earn revenue, the build free experience is no longer available as a packaged up application must be built.  Building in this case with Python is as complex as building with Kotlin, and often more complex than with Kotlin, largely because the Python build is a less common case, so gets less attention.

Python: With respect to building, python is at its best for programs written to be used by the developer and other programming colleagues, or for web servers or web services.

All kotlin programs require building. For “hello world” it can be so automatic you will not notice, but you will notice soon, even if only building programs for you own use.

However, the build systems available with kotlin are more consistent and more powerful. In fact, some notable large scale python projects like linkedin use kotlin ecosystem build systems. Despite the desirability of the kotlin approach, building in python is scattered that developers moving to kotlin can have their be the first ever exposure to build systems when using kotlin.  Note: in an ideal world, all python projects could use the same build system as other languages such as kotlin  (as is the case with linkedin).

There is a learning curve to building with kotlin, and that will be nice shallow curve if you keep it simple or a very steep curve if  try to learn the most advanced building possibilities at the start (when you don’t need them).

Kotlin: you can have one build system to build everything, including professional application, in place of the several different systems needed with python, and the power available is so compelling that advanced python users invest considerable resources to making the same system available with python.

This makes getting your first app running easier with python, but the first time you want to share an app much worse.