I wanted to make a post to compile some resources for creating Python apps in PortableApps.com Format for interested developers. Currently, we have two apps released in our app store using the PortableApps.com Launcher that are Python-based: gPodder Portable and Solfege Portable. We also have GIMP Portable which utilizes Python for some functionality and Gramps Portable which uses an old-style custom NSIS launcher, but they're outside the scope of what we're discussing here. All of these apps bundle a full Python runtime within them to operate. Solfege Portable instantiates the Python runtime pythonw.exe directly to work while gPodder Portable runs the gPodder.exe launcher to instantiate the bundled Python. Other than this minor difference, the apps themselves aren't much different than any other app we have. gPodder Portable uses environment variables set by its launcher to direct gPodder to store data within the contained Data directory while Solfege Portable relies on its launcher to move directories to and from the local machine's Documents and APPDATA folders for portability.
The relevant beginning of gPodder Portable's launcher INI file is as follows:
[Launch] ProgramExecutable=gPodder\gPodder.exe WorkingDirectory=%PAL:AppDir%\gPodder DirectoryMoveOK=yes SupportsUNC=yes [Environment] PATH=%PAL:AppDir%\Python\PyDLL;%PAL:AppDir%\Python;%PAL:AppDir%\Python\Lib;%PAL:AppDir%\Python\DLLs;%PAL:AppDir%\Python\Lib\lib-tk;%PAL:AppDir%\gPodder\src;%PAL:AppDir\gPodder ;PATH=%PAL:AppDir%\Python\PyDLL LANG=%PAL:LanguageCustom% GPODDER_DOWNLOAD_DIR=%PAL:DataDir%\config\Downloads GPODDER_HOME=%PAL:DataDir%\config PYTHONHOME=%PAL:AppDir%\Python PYTHONPATH=%PAL:AppDir%\Python\Lib;%PAL:AppDir%\Python\DLLs;%PAL:AppDir%\Python\Lib\lib-tk
For completeness, when we used to launch pythonw directly in gPodder Portable, the first two lines were:
ProgramExecutable=Python\pythonw.exe CommandLineArguments="-m gpodder"
The relevant beginning of Solfege Portable's launcher INI file is as follows:
[Launch] ProgramExecutable=Solfege\bin\pythonwSolfegePortable.exe CommandLineArguments='"%PAL:AppDir%\Solfege\bin\win32-start-solfege.pyw" --no-splash' WorkingDirectory=%PAL:AppDir%\Solfege\bin DirectoryMoveOK=yes SupportsUNC=yes [Environment] PYTHONPATH=%PAL:AppDir%\Solfege\bin PYTHONHOME=%PAL:AppDir%\Solfege\bin HOME=%PAL:DataDir% [DirectoriesMove] SolfegeSettings=%APPDATA%\GNU Solfege SolfegeDocuments=%DOCUMENTS%\GNU Solfege
Both apps are available for download for interested developers to use as a starting point for their own Python-based apps they'd like to package in PortableApps.com Format.
I'm looking to make the Windows Python runtimes available as a CommonFiles plugin in the near future as well. This will be similar to how we currently release Ghostscript, GPG, Java, and JDK. We'll make both Python2 and Python3 available and let the apps specify which they need to platform.
Having Python based application and Python as "Common Files" would be great.
Will it be an incentive to have WinPython as part of the suite as well?
Other than the fact that some Python apps might use a package that wouldn't be included within the CommonFiles plugin, I'm all for this to happen.
Commonly used python packages would need to either be included in the plugin (permissions withstanding of course) or a plugin made for adding the package if required by an app.
Of course, only packages used by official PA.c Python apps would need this, with others getting added as more apps use them. Devs of other apps could make their own plugin installer (an online installer if permissions aren't obtained) to add required packages.
Generally, updates to Python should not affect whether or not the installed packages work after updating, though reinstalling packages is usually safer.
"For the sake of completeness", I took a look at all the current official PortableApps.com releases to see which ones were Python apps, and which ones use and bundle Python.
The following is a list of my findings...
There are actually 'a few more' Python based Apps here, several of which use PAL:
4st Attack [PAL]
Feed Notifier [PAL]
Lucas Chess [PAL]
MusicBrainz Picard [PAL]
Task Coach [NSIS]
There are also a few more apps which make use of Python in some way or other and include a copy of it:
Then there's a few that can use Python, but don't appear (at least currently) to include it:
There's even one that seems to use, and include, a different implementation of Python:
And this one looks like it has some relationship with Python too, but I'm not sure what it is:
One thing to be aware while we're looking into this, is that for applications including a copy of Python, they may not allow using an external version.
For example, Blender programmatically assigns the Python location using Py_SetPythonHome, which explicitly ignore the PYTHONHOME environment variable. I wouldn't be surprised if some of the others do the same.
In the list above, for those applications that don't set a PYTHONHOME or PYTHONPATH value to run, we may not need to make any changes whatsoever to their packages.
In the case of gPodder, I'm comfortable with us linking to an external Python copy as discussed, for Solfege it appears we may have compiled in support ourselves, so we can likely link externally as well.
Any further development for Python runtimes? What about portable Python development environments?
I'm up to assisting in whatever capacity that may be helpful.
Dan "FloriDan" Carroll
Just an old hacker having fun.
We're still debating it due to the variety of builds Windows apps are including. As for Python development, if you have a specific suggestion for an IDE+Python you'd like to see, please post a Request Apps forum post with it.
Sometimes, the impossible can become possible, if you're awesome!