New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GSOC 2019: Nuitka one file standalone option #230

Open
kayhayen opened this Issue Jan 26, 2019 · 42 comments

Comments

Projects
None yet
5 participants
@kayhayen
Copy link
Member

kayhayen commented Jan 26, 2019

Project description: Nuitka has a mode meant for distribution to another system
that puts everything needed in a single folder.

One complaint often raised is that it's a folder rather than a single file, for alternative packaging methods, e.g. py2exe and pyinstaller, these do actually exist, and this project would be about integrating with that.

In a first stage, you would identify the code of these tools that is doing it and try to port it to Nuitka for one or more platforms.

Skills: Python programming, Linux and/or Windows installs of Python, both would be great.

@kayhayen kayhayen changed the title Nuitka one file standalone option GSOC 2019: Nuitka one file standalone option Jan 26, 2019

@kayhayen

This comment has been minimized.

Copy link
Member Author

kayhayen commented Jan 26, 2019

There is already #16 for this, where people have expressed there wish to see this. Being busy with implementing the optimizing compiler, we lack the resources to this ourselves, but it would be a great way to contribute for a student, and we would gladly mentor this.

@GiridharPrasath

This comment has been minimized.

Copy link

GiridharPrasath commented Feb 5, 2019

hey @kayhayen i would love to work on this.I'm comfortable with C,x86 and python.
I am going through the developer manual and can you help me on where to start with to completely understand the internals

@kayhayen

This comment has been minimized.

Copy link
Member Author

kayhayen commented Feb 5, 2019

That is great. You definitely need to look at:

def detectUsedDLLs(source_dir, standalone_entry_points):

def copyUsedDLLs(source_dir, dist_dir, standalone_entry_points):

On the C side, there is code in Nuitka like this:

static void prepareStandaloneEnvironment() {

So one task is collection of the dependencies, that all works very well. What then will be needed is to make some sort of self-extracting binary. This part I really have no idea about myself except that these other projects have solved it, and in part it would be your task to find out how they do it @GiridharPrasath

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 5, 2019

I can step in with the self extracting stuff a little bit.

Solution 1: General Background

  • The dist folder must first be packed (ZIP format or 7zip)
  • at the "front" of the the resulting file a small program needs to be glued, that does the following:
    • take the ZIP part attached to its end and unzip it to a temporary folder
    • execute the EXE file (there is only one!) in that temporary folder, passing any invocation arguments to it.
    • upon return from the invoked EXE, delete the temp folder again.

I have a part solution of the above, based on 7zip on Windows. See attached below. It does have a few issues:

  1. 7zip must be installed
  2. the "frontending" unzipper ("sfx") must be available
  3. The resulting selfextracting archive itself is an EXE and behaves exactly like the compiled Python script, except that it requires authorization (Windows UAC). I don't know yet how to resolve this. Probably, I will have to write a self extractor stub myself.
  4. Every execution does the unzip again, before the actual compiled program starts - so startup will be delayed by this.
  5. This is the type of solution also implemented in PyInstaller.

self-extract.zip

Solution 2: General Background

  • This solution needs more investigation
  • the frontend stub for the zipped dist folder does not unzip it but directly executes the compiled program from memory
  • the stub also establishes a "redirection" such that dependent binary file calls (DLLs, PYDs) will cause the binary to be read / decompressed and loaded as if being read from disk. This technique (developed by some guy Joachim Bauch) is called MemoryDLL.
  • MemoryDLL has been implemented in the script language AutoIT, and apparently also in py2exe.

An elegant solution, but as I said, this need more investigation. E.g. I cannot image how this may work if your dist folder also contains data files!

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 5, 2019

I am using solution 1 for some of my projects, and have several 7zip sfx codes that require or not Windows UAC depending on the manifest (I actually reshacked them).
I must admit that this solution is quite bad, especially when needing to pass arguments to the SFXed executable, which is a real pain in the ***
There is also the fact that several 7z sfx implementations exist, with different syntaxes.
Also, this technique is quite slow depending on the distribution size and compress options.

I am in favor for a SFX implementation since Solution 2 would virtually require a ramdisk like squashfs, but 7zip SFX isn't the best option I think.
I'd love to see an implementation that uses LZ4 or zstd in order to achieve good startup speed, but those don't have ready to use SFX implementations as of today.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 5, 2019

The SFX which I included up there, does hand over parameters no problem. I must say, it took me many hours to find it, though. It is also zero-config: it automatically starts the first executable file in the decompressed folder. Seemed quite cool to me: got my test running in a rush.

And (a gooddie especially for you ;-)) the compression ration is much better than UPX: a 48.8 MB dist folder becomes a 12.8 7z file ...

@deajan, if you could send me your SFX examples, that would be great. The big advantage of using 7x is its superb compression ratio, and its very high decompression speed.

If I could get hold of an SFX source, that might be another starting point, once a solution for how to create ramdisks has been found.

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 5, 2019

Where does your sfx program come from ? 7zip version 9.20 ?
My 7z sfx require a config.txt file that is copied between the sfx and the archive.
Newer version 18.05 does not seem to "just run" the executable inside the archive.

Why not go the NSIS way, which is cross platform compatible ?

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 5, 2019

As I said: took me a while to spot this version:
For some reason, develpment of those SFX guys seems to be draining.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 5, 2019

Downloaded NSIS and tried it a little. Looks promising.
Although I could not figure out yet how to start the EXE as part of the "installation". Not to mention how to pass arguments to it ...

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 5, 2019

@deajan Update: NSIS was an excellent hint!
I am now able to do the same as those SFX installers:

  1. create a 1-file EXE from the script's standalone dist folder - LZMA compressed.
  2. when executing this file, the dist is extracted and the script's EXE is executed - whith any invocation parameters passed in.
  3. all this completely silent - no pesky Windows UAC popping up.

Now the whole procedure just needs to be packed into a script and we are done with my "Solution 1" from above.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

Just uploaded a first version of a OneFile creator script.

It is based on the (excellent) installer creation tool NSIS, which was suggested by @deajan.
It currently works on Windows - maybe @GiridharPrasath you want to look at it and try extending it to other platforms?

What it does:

  • to be used for creating an installation executable from the dist folder of a standalone compiled script
  • has the same name as the exe file of the script
  • when invoked on the target system, it will decompress itself on the user's Desktop and then invoke script.exe inside the dist folder. So this installation file looks and behaves like the actual program. This includes any command line parameters, that may have to be passed in.
  • after finishing the program inside, the folder again deletes itself.

There are other ways to use this installation file:

  • you can just decrompress it and extract its content like with any ZIP file (e.g. use 7zip to do that)
  • you can invoke it with an extra command line parameter /D= to specify an alternative installation folder.

To use the script, the installation making software NSIS must first be installed. The onefile-maker.py is actually just a front-end to this software: it creates an installation script, which is being compiled by NSIS.

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 6, 2019

Seems nice, now using this script entirely via commandline should be a viable option so it gets integrated into Standalone.py
Also, a download routine for NSIS will be necessary, otherwise there has to be a --nsis-path= parameter.
At last, some options could be passed as arguments, including:

  • AppName
  • Company
  • Description
  • Version
  • Icon file

Also, there should be default values for these.

@JorjMcKie Do you want to handle this ? If not, I can step in.

@GiridharPrasath

This comment has been minimized.

Copy link

GiridharPrasath commented Feb 6, 2019

hey @JorjMcKie @deajan ,

Now i could completely understand the issue,as i'm a newbie here.
and i assume that this link discusses the same.

Correct me if i'm wrong.and i will look upon to extend to other platforms.

@kayhayen

This comment has been minimized.

Copy link
Member Author

kayhayen commented Feb 6, 2019

That stackoverflow question @GiridharPrasath doesn't do a lot solution. The build script used will also use options that were removed, e.g. --python-version=3.6.

In my mind, the first step, and this is where your research skills would come in, is to find out, how and why pyinstaller --onefile works. Nuitka can freeze bytecode and contain it all in the binary, and make imports of .pyd (Windows) or .so files (Linux, etc all) from the file system.

From a presentation I saw years ago, there is a shared library loader re-implementation that is being used at least by py2exe. So instead of from disk, shared libraries are loaded from the single file binary, which is normally not allowed, and why it takes a whole new implementation on Windows, but fortunately that would have been done already.

I have no idea, how or if they also how file open, to also give file handles to content contained in the binary, but they might also have that.

So do we design from scratch, or do we look at what others already got first. In my mind, pyinstaller --onefile seems to work pretty well. I have seen it used for tools on Windows for distribution even via pip, not sure if that is good or near necessary, but it works. For now I just want to steal/share from there, and doing that research, and integration into Nuitka will be enough of a challenge if you ask me.

But then I am lazy and most of you are not. :-)

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

@GiridharPrasath - yes, goes sort of in that direction.
I believe the issue discussed in that link has been addressed by now via this exe-maker2.py script.

And yes, it would be great if you would look into Linux and/or OSX to see how this thing might work there.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

@kayhayen - maybe you have seen my comments on that py2exe solution. Its basis, MemoryDLL goes very deep into Windows specifics, it effectively mimics the DLL loader of Windows. I am very sceptical that there is a similar thing on Linux etc. py2exe consequently only ever worked on Windows as far as I know.

It does not do other things than loading DLL and PYD files. Which means: if my dist folder also contains data files (easily happens, e.g. certifi data, TCL/TK libraries), I am lost.

PyInstaller does what we now are about to do as well, namely making a file that installs itself and immediately afterwards executes the program.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

@deajan -
I agree: quite a lot still needs to be done.

  1. Make sure NSIS indeed also is the viable solution for non-Windows platforms

  2. Make design decisions:

    • lots of new parameters, exclusively for standalone! It seems to me, some (the company ones) should be fairly constant - the same across several applications. In addition to your parameters, we need to think about e.g. license and copyright. So we should think about creating a publisher / deployment profile type of thing associated with distro generation, which contains the defaults.

    • not every standalone compile should automatically entail creation of distro material. That should be an option. For instance, in all cases I would first want to make sure, that the compile indeed created an executable app, or if anything went wrong, or if unneeded components can be opted out, etc. I believe we therefore do need a separate step being available, too, which makes the distribution after a level of certainty has been achieved via such tests.

    • I am sure not everyone wants a OneFile distro format - in the sense that deploying, automatically also means execution rightaway. I certainly don't. So we need to decide on adequate possible deployment formats, OneFile being just one of them (and probably not the most professional one, allthough an option of its own right).

  3. I do agree: we need to decide where to put the NSIS download / installation decision in the gloabl Nuitka context. I remember, that the "old" dependency walker employment is controlled by an option inside the Nuitka invocation. Something comparable seems required again. Best maybe as part of the Nuitka installation itself ...

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 6, 2019

@JorjMcKie NSIS isn't multiplatform, but allows cross platform compilation
I don't think we'll have a multi platform compatible solution that does it all, since Win/Unix/Mac are way to different OSes :)
On linux, a shar like solution would be fairly simple to implement.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

You are right. I didn't look closely enough before, sorry.
So our new supporter @GiridharPrasath has a bit more to clarify ...
@GiridharPrasath: what is the platform you are working on normally? Linux?

@GiridharPrasath

This comment has been minimized.

Copy link

GiridharPrasath commented Feb 6, 2019

@JorjMcKie Yeah,I am using debian(Kali)

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 6, 2019

@kayhayen The current PyInstaller --onefile implementation is seen as trojan by 11/61 antivirus scanners of virustotal.com, hence rendering it a pretty unusable solution to me.

@JorjMcKie Thinking about it, on Linux a squashfs solution could be perfect. There is always Python PAR format, and more recently Facebook opensource XAR implementation (which btw does zstd compression), see https://code.fb.com/data-infrastructure/xars-a-more-efficient-open-source-system-for-self-contained-executables/

@GiridharPrasath If @kayhayen thinks this could be a good solution, maybe have a look at a Linux XAR implementation for --onefile ?

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 6, 2019

I think we need two different --onefile implementations, for Unix and Windows worlds.
Windows 'ramdisk' won't be feasable, because it would require installing a system driver on the fly, making all binaries depending on UAC.
Since we're stuck to Windows archive technique, NSIS does all the polish around the archive.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

@deajan, @kayhayen - agree with Orsiris. I have looked into the resp. source code of PyInstaller. It is written in multiplatform C and does what the NSIS solution does: decompressing / copying what it has in its rucksack (to a temp dir), then executing the main script from there, and delete the whole bunch.

And @deajan, yes we do need a totally different onefile software approach on Linux vs Windows - I see that clearer now.

This also underpins my comments on the limited reach of onefile solutions on Windows. While it is certainly good to have this option, it quickly becomes unhandy when we talk about dozens of MB of deployment size - even for simple applications. Being able to select a fast deployment folder (ramdisk / ssd) is probably the best we can offer to people who want this.

@deajan - let me ask you this:
If I understand the squashfs concept correctly, it is a special filesystem, designed for readonly data and in a highly compressed format.
If I deploy a Nuitka file to such a device, it would still have to be (1) decompressed, and then (2) stored on the squashfs device using that device's compression, then (3) executed from the squashfs device, right?
If yes, that would still entail all this overhead for every OneFile execution (because, as per design of the approach, the installation result is deleted again after program execution).

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

I have just looked into that XAR thing description. This indeed looks extremely promising!
It does overcome my points in the previous comment. Certainly worthwhile looking at, @GiridharPrasath.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

XAR obviously does not exist for Windows.
But there are container formats, which are mountable as disks (like wim). I will at least do a few checks around this possibility.

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 6, 2019

@JorjMcKie The XAR format allows to use FUSE to mount squashfs, hence no need to be root, but on Windows, there's no way to mount a wim without being admin, also, it won't be executable without a script.
Hope you find something better, but as of my understandings, there's no other way than a plain old SFX.

@kayhayen

This comment has been minimized.

Copy link
Member Author

kayhayen commented Feb 6, 2019

I hate to raise it, but if we focused on new Linux OS only, do we consider https://flatpak.org/

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 6, 2019

Flatpak / snap packages need to be installed in order to run whereas sfx / xar / par solutions are simple click and run. This would be a huge drawback for Linux distros that don't support flatpack / snap packages IMHO.

@kayhayen

This comment has been minimized.

Copy link
Member Author

kayhayen commented Feb 6, 2019

I see @deajan I thought they might just run instantly, provided the OS has flatpak support. And given that standalone is often used to address very old systems, OK, no way.

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 6, 2019

If someone has enough C knowledge, the solution used in cx_freeze could work too, https://github.com/anthony-tuininga/cx_Freeze

There's also a fairly simple solution (the shar like) https://github.com/megastep/makeself which simply includes an archive as binary blob in the file.

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 6, 2019

And there's AppImage too.... Which would probably solve GUI applications running with a shell.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

@deajan - yes, WIM is not an option because of the inevitable elevated priviledge requirements. But still ISO might be. There is even a Python library to create an ISO image from arbitrary files.
Mounting ISO is possible on more recent Windows systems, and there is thridparty SW available for older ones.
Actually mounting an ISO does not require priviledges. But there would be research required to find out ways how to automatically do that.
And then bot, WIM and ISO do not compress the files by themselves. A UPX run would be required for a dist folder before ISO-ing it ...
A lot of "if" ... and for what?

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 6, 2019

@JorjMcKie I personally found find it very strange that a simple app would require mounting a virtual drive... That's a lot of headache for not so much, not talking about initial execution speed.
Why not Zoidberg ? Ehhhm I mean NSIS ? It seems to be a good solution for Windows anyway.
(V)(;,,;)(V)

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 6, 2019

@deajan - yes, exactly that I was aiming at.
It will do its jobs and it will do it well. It also is extensible enough to evolve the whole rollout of Nuitka applications to something as professional as we ever want.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 7, 2019

@deajan - coming back to your recommendation re https://github.com/megastep/makeself:
Should we ask @GiridharPrasath to look into this?

@deajan, @kayhayen

  • I made another change to onefile-maker.py: if the installation file is invoked with parameter /D=<folder>, it now decompresses the dist folder into that directory and exits. If invoked without this parameter, it will decompress into the user's temp directory and execute script.exe (= the compiled script.py) and pass its own invocation parameters to it. After this, the temp dist folder is removed again.

  • I was thinking about @deajan's suggestion to include more parameters in the installation material generator (aka onefile-maker.py). And indeed we also need logic to include the potencial download and parameterization of things like NSIS, ...
    While I believe he is very right, the explosive growth of parameters in every corner should be a concern!
    How do you feel about designing some type of parameter store for all of this? It should come pre-populated with defaults during Nuitka's installation, and be modifyable later by the user.

    • it should support sections for various topics like download approvals (Dependency Walker, NSIS, ...), standard standalone parameters (experimental flags, user/company standards, copyrights, licenses, logos, ...), execution of UPX, etc etc
    • it could be based on some standard format (INI file, JSON, SQLITE) and reside in the user's home folder
    • we would need a maintenance component for this
    • Standalone.py could pick the variables from there, the command line would only contain overwrites, extra scripts we have now (exe-maker, onefile-maker, ...) or may need in future could be invoked (or triggered) automatically based on those values
@akshai9899

This comment has been minimized.

Copy link

akshai9899 commented Feb 8, 2019

Hey @kayhayen and @JorjMcKie , I would like to work on this if that's okay :)

So from this comments thread and my searching, this is what I got, correct me if I'm wrong.

  • We want to put the output dist folder into a single file that can be executed directly.

  • Solution 1 is making a sfx file which can extract itself into a temporary directory and execute the file in it, preferably it'd be good if we can provide arguments to it

  • Solution 2 is using MemoryDLL by joachim as in py2exe and this gives a nice overview of it https://sourceforge.net/p/py2exe/mailman/message/1390732/

  • The solution 1 in using NSIS which can be compiled in both Linux and windows but the generated installers from NSIS works on windows only.

  • XAR seemed to be a nice solution to me but it's not so useful in Windows as suggested in comments

And this is what I did and I am using Debian Ubuntu 16.04, I also have windows 10 if it's required.

  1. Using the standalone option, on one of the test files in tests/standalone made a .dist folder.
  2. And using this repo https://github.com/megastep/makeself as suggested by @deajan . I was able put everything into a .sh file giving it the option to execute the required executable file after extracting. Also optionally one can provide a script(shell script) during the making of the .sh file to be executed after extracting.
  3. And this worked nicely! also one can provide arguments to the .sh file that can be sent as arguments to the script embedded in .sh file.
    Still more tests are to do be done.

What this repo does in detail :

It has a shell script that can generate a self-extractable compressed tar archive from a directory. The resulting file appears as a shell script. Using this file, the archive will then uncompress itself to a temporary directory and an optional arbitrary command or a script(shell script) is executed. Being just a shell script it is portable to most of the systems.

So this can be the solution 1 in Linux

Also I'd be happy if someone points the direction to work on further

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 8, 2019

Hi @akshai9899 - this sounds just great!
Taking "your" (makeself) and "my" (NSIS) solution together, we have covered Linux (plus others IX systems) and Windows systems.
This brings us close to fixing the issue.

Commenting the "Solution 1 & 2" discussion:
As I said previously: there will be no solution 2 on Windows any time soon, because data files cannot be covered by something like MemoryDLL (only works with binaries similar to .so libraries on Linux).

If this XAR thing is generally available on Linux (which it isn't yet, I understood), then it indeed represents my "solution-2" definition, because it covers all sorts of data (shared library binaries and data files).
I am not aware of anything close to this on Windows.

So conclusion would be to wrap up what we do have (with Mac OSX still being a missing puzzle piece):

The dist folders, the results of standalone compilations, can be converted into installation files, which can be either deployed to the target system or executed there like normal programs.

What is left to be done is cleaning up some things:

  1. decide / implement how to connect compiles with this creation of installation files:
    • via an additional option in the standalone compile
    • as a separate run
  2. design / implement on additional information to be included in deployment data (see @deajan's comments above): company name, copyright, license, application name, ...
  3. investigate what can be done on Mac OSX

If you could pick up points 1 and 2 and come up with suggestions, that would be great.

@deajan - what is your assessment on this?

@deajan

This comment has been minimized.

Copy link
Member

deajan commented Feb 13, 2019

Seems good so far :)
Now IMO, the --standalone switch should have another subswitch like --singlefile which triggers a separate Python file that does the makeself / NSIS magic.
Since both Linux and Windows methods are completly different, they should be implemented in two different files, ie Singlefile-unix.py and Singlefile-win.py
The windows version could accept a simple JSON file with the required additional information.

@JorjMcKie I'll have to deal with NSIS these days in order to generate some other files (nothing to do with Nuitka), is there any help I can provide ?

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 13, 2019

@deajan - I agree ... with clarifications:

  • what is the difference between OneFile (SingleFile) and other packed formats? As I wrote somewhere else: if you specify a target directory via the /D=<folder> parameter, it will decompress the dist into it und fertig. Potentially, the NSIS / makeself stub could be marginally modified thus, that it "knows" it must ask for <folder> if it is not OneFile.
  • additional parameters (like you named a few):
    • where should they go? As data files copied into the dist folder?
    • why only Windows - Linux should have the same requirement, shouldn't it? Of course with some exceptions like console (although MAC seems to have that too) and the app icon, but both are already options of Standalone.py.

As per NSIS: thanks for the offer. I'll come back when questions pop up. I am still digging into it ...

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 17, 2019

@akshai9899 - any update on this?
How about making a script similar to onefile-maker.py for Linux?

What I am going to change in this version for Windows:

  • include options in the GUI to either create an executable as I have it now, or to create an executable which allows entering a desired folder at the installing site
  • include more meta information (see @deajan's and my comments above) like app-name / description, company-name, license, ... It is still unclear how to deal with this information: should they be pointers to text files, which then must be copied into the dist folder ...? Your ideas welcome!

After we have OneFile maker versions for Linux & Windows, I want to extend the standalone portion of Nuitka compile with options to trigger OneFile creation, and potentially more.

@akshai9899

This comment has been minimized.

Copy link

akshai9899 commented Feb 17, 2019

@JorjMcKie Sorry, I started it but I had to stop with my University semester examinations going on :(
I will send a pull request by the start of the next week, and as my exams will end by then and I can work more freely on Nuitika on extending the standalone and more

This was my plan so far on the onefile for Linux (I will be adding more next week along with the initial pull request) :

  • Check if a download of https://github.com/megastep/makeself exists in present dir or if a path is given, if not download it. Including options for the executable and the embedded script (quite a few choices here). I'll mostly try to keep options the same way as Windows version so it won't confuse users.

  • I'm thinking of executable --help to get info about publisher and information as this seems more Linux. I don't know if this is a good idea though.

@JorjMcKie

This comment has been minimized.

Copy link
Member

JorjMcKie commented Feb 17, 2019

@akshai9899 - no worries, your education certainly is top priority!

Your plans look good. Displaying help is a good idea, too. How "professional" we want to

In my mind, standalone compilation's (let me abbreviate it: SAC) purpose in life is to produce installation material for other sites (which may have a different configuration than the origin).
This material always is one executable file (with attached-to bundled, compressed stuff).
There are 2-flavor format differences only pertaining to: what happens if that file is executed. Either

  1. the embedded script is executed with any arguments passed through to it
  2. the executable decompresses its content to a given location and in general completes the installation (platform specific variances).

The decision between the alternatives is made on the creating site - as well as some more sub-alternatives maybe on the Linux side (which IX-variants to support via different comrpession formats and what not). Iwouldn't be too concerned about the last point: people compiling stuff should know their platform and be used to it - subtly different Nuitka behaviour on some other platform is a matter of course.

Please notify me when you have more time again to discuss additional design approaches, e.g. for keeping the Nuitka parameter inflation under control by using configuration profiles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment