The current Python XARs rely on Python being on the system path. But it would be easy to build a custom Python XAR with the XAR builder library that includes the Python executable and makes sure to use the packaged executable.
XAR is only for "Linux or macOS", with FUSE installed.
PyOxidizer offers a solution that:
- works on Windows
- can produce executable for Windows, Mac and Linux, but also potentially cross compile from any of those in the future
- results in a stand alone executable, not some filesystem abstraction
- as such, the target machine doesn't need to have anything installed
- it also offers to embed Python into Rust projects, and Rust into Python projects
A better alternative would be the excellent nuitka (nuitka.net):
- it compiles Python to C
- it's very compatible, very reliable (I battle tested it)
- works better than the alternatives like py2exe, cx_freeze, etc
- does provide a standalone executable
- more mature that both of these projects
But:
- no cross compilation
- no rust / python interoperability
- more complicated to get working on windows
So I'm really excited for PyOxidizer. It may make the task of providing a stand alone executable even easier than with nuitka, and as a bonus, may build a bridge between the Python and Rust community, which really are meant to play together.
Yeah! pyinstaller is an example. They do it by bundling a standalone python interpreter (x-platform ones too) with the necessary python libraries bundled in, just like you suggested
Why would you invlove the kernel at all, since you have access to Python's code itself, and can just make your own version of python, that will source files from wherever you want. And your package will be protable to Windows, too.
XRDPConfigurator itself is available to try out - versions currently available for Ubuntu 14 (.04 & .10) 32 & 64bit, and Debian 7/Wheezy 32 & 64 bit. I'm in the process of producing packages for additional distributions - the difficulty being making sure the python libraries the application uses are available in the target distribution.
The program was written entirely in Python, compiled to C via Cython, and subsequently compiled to object code dynamically linked to the python libraries.
I am however considering treating the Python version as being "the application was prototyped in Python" and re-writing it in C++, as that would help to solve dependencies on PySide and other python libraries - that might not be viable on my part due to not having done C++ for a long time. We'll see how that goes.
The xrdpconfigurator.com site itself is still a WIP. I'm busy making more content.
The application took me roughly 8 months to develop from scratch - a lot of that was due to Xrdp having lots of new features added to it in that time, which I just had to implement - the big one being the xrdp login window was made a lot more customizable.
The biggest challenge is time, and prioritising what gets done first - I'm a massive team of one who's doing _everything_ from setting up the web site (itself using django and weaving together djangocms, zinnia-blog, and oscar for the licensing shop back-end), running and maintaining the web and email servers, developing the product, producing the distribution packages, creating the site content, attempting to tell people about it (marketing ;) ) and probably lots of other stuff I've forgotten to mention :)
Xmake built-in luajit, without any external dependencies, can be used after installation, although most distributions have built-in python, but there are still many systems that do not install python by default, such as windows.
You can actually use Python as a configuration file pretty well, if you need more complicated logic and macros. Otherwise, sticking to a toml or ini file is my preference.
reply