Make sure to use 0.6.16.5 due to many fixes / always try develop before reporting, actual reports to Github, Commercial people go here: https://nuitka.net/pages/commercial.html
as a side note, interestingly the executable under windows produced by github actions is about a megabyte larger than the executable produced under WINE (both are using the downloaded mingw!)
6 replies
I'm not too worked up about the difference, but I thought it was unexpected (maybe it's because the WINE stuff is getting bundled and it's a different size?)
I'd have to examine more what windows stuff nuitka packs in
to get pip running under WINE I found one of the portable python distributions to be easiest if you want to go the route of trying to reproduce it
one sec I can make a bash script to do the WINE stuff if your'e not familiar with it
@kayhayen here's a bash script that would get you up and running in WINE https://dpaste.com/4VZZ7ZBUL note you need to harvest a 64 bit mfc42.dll from a real windows installation to get it working (it's required by the depender tool, so therefore it's required to get the WINE running)
it seems quite likely this is a WINE-specific bug so I want to emphasize again I'm not convinced this is within the scope of what could be considered a nuitka bug or otherwise worth your time, but that should be everything you need if you want to go that route
maybe mkdir -p for the wine prefix directory but yeah
the one step obviously you need to grab the .whl from the project
actually you can just install it from pypi
too
:)
to reproduce what you need to do is edit the tox.ini so the output is to a nonexistent path, then run
tox -e nuitka-winunder WINE
to clarify, the relative folder path is what needs to not exist
@Saif_Maruf_twitter if you have an issue, try Github, this is not nearly enough information, but I can assure you they normally do work fine :)
make sure to use develop and checkout anti-bloat ... some packages are having a lot of dependency creep, and it has options to turn imports to ImportError at compile time, and often than can make huge differences, I fought with numpy and scipy some, and next is pyqtgraph ... thing swill include setuptools, ipython, and essentially every sytax color engine on the planet, if you have on of certain things included
I think even Pandas has become more managable after some of this work.
But generally with 40m I am relatively happy, it's a diverted struggle to get performance at run time up, at compile time, and bugs solved, all at once :)
Usually compile time performance is loosing out. But in the last 6 months, lots of things have improved, and more to come this winter.
@gabeauregard_twitter currently Nuitka is stupid and includes all of stdlib, mostly because it has no dependency analysis of it, due to not compiling it, mostly because scalability would so poor otherwise. For now, just remove tkinter from your python install, or venv, or whatever, and it will be good. Deleting files in your Python installation is a robust way. Caching has been made more possible with a PR, we actually now can provide the dependencies and save it to a file, but restoring that has not been yet made operational, as there were some issues with that, but there shouldn't be huge things. I expect this to arrive this year, and then we can compile things once until they change, on a module level only, and then include it still as bytecode or not, but only used parts of stdlib.
Unfortunately due to dependency creep, everything uses lots of things it doesn't use, which uses even more things, a single "import setuptools" in a branch is killing scalability, for now anti-bloat allows to force those into ImportError should they be actually done, which they often are not.
The yaml file behind it needs docs but is very user accessible, I expect you people will be able to contribute to Nuitka with it easily, removing useless imports and codes from the compilation.
I tried follow-stdlib for fun, but the resulting binary either complains about lack of site module or segfaults if I add nosite flag
looking at the code it seems they both work
not sure what's wrong with the follow-stdlib though
@gabeauregard_twitter the standard library may have issues that are not looked at, because it's not default and not tested. I will look at help text now, should only mention one, they are aliases though
I prefer the one with the "_" in the name usually
Not sure how the stdlib being compiled would affect site module, I think it's stdlib too
@gabeauregard_twitter please raise it as an issue, very probably the specific version will matter, and it's good for me to look at it, may always be a general issue
you were right, installing python without tkinter worked fine (and decreased the binary size by over a MB), but there's probably not a clean way to integrate this into the github actions build so I won't worry about it. I had tried to use MSVC on github actions instead of mingw to try out LTO effect on binary size, but I gave up wrestling with github actions before I got it working
I prefer the one with the "_" in the name usually
--standalone mentions "no_site" and --python-flag mentions "nosite"
@kayhayen regarding dependencies like Jinja2, MarkupSafe, setuptools: I'd be fine to add them to my environment myself instead of Nuitka having them shipped. However, I think it needs to be mentioned in the readme (perhaps with what versions Nuitka is tested against) and I could also lookup the required versions from requirements.txt . It was just confusing first time when I faced the issue.