Nuitka Progress in 2015 – Python Compiler • Hacker News Board

Re: Nuitka Progress in 2015 – Python Compiler

#51

Post by marssaxman » Sat, Jan 30, 2016, 1:48 AM UTC

_yy wrote: post #27

falcolas wrote: post #25

Earlier quoted context omitted.

> update the shared library, restart affected services ... look for programs to break at runtime because of some unrelated API change in the shared library.

That's why Debian Stable and RHEL exist. Security patches don't break the API.

I am willing to believe that they come closer to the ideal than others, but nobody is perfect, and I'd rather discover incompatibilities myself, when I'm getting a new version of my app ready, before shipping, instead of trying to understand why random users are incoherently reporting impossible app failures.

Re: Nuitka Progress in 2015 – Python Compiler

#52

Post by disillusioned1 » Sat, Jan 30, 2016, 4:31 AM UTC

The Requirements section of the user manual says that in addition to a C++ compiler, you need Python2 at compile time even if you're using Python3, due to a requirement of the Scons tool.

Re: Nuitka Progress in 2015 – Python Compiler

#53

Post by im_down_w_otp » Sun, Jan 31, 2016, 4:36 AM UTC

objectified wrote: post #10

rwmj wrote: post #8

Earlier quoted context omitted.

I find the way software is packaged in Go to be a terrible regression, but I'm more interested in why you think pip and venv's don't solve the problem for Python already? Edit: I see from your reply that we're talking at cross purposes. I thought you meant source distribution, but you mean binary distribution to end users or deployment to production systems, and in that case I agree with you.

Being able to ship a self contained binary of your application is a very powerful concept, on which many seem to agree. The way I see it, pip and virtualenv are not practical for deployment or distribution. You shouldn't have to download and install things during a production deployment. I even created a tool ( https://github.com/objectified/vdist ) to mitigate this problem, but it will always be a hack when doing it…

Why not just follow the Erlang/OTP practice of creating a "release" which contains everything you need, including the runtime system, deps, and your code into a self-contained tarball?

Re: Nuitka Progress in 2015 – Python Compiler

#54

Post by _yy » Fri, Feb 05, 2016, 1:50 PM UTC

IshKebab wrote: post #44

_yy wrote: post #12

Earlier quoted context omitted.

Remember that critical Go security update? Usual procedure - update the shared library, restart affected services. Go - recompile everything.

Yeah that's the usual refrain, but the only situation where you have shared libraries is on Linux with a package manager. In that case it is trivial to recompile all packages that depend on the insecure library anyway. On Windows you have to package most shared libraries with your app anyway so you have to get a new version of it anyway.

Sure but that's one of the reasons I use Linux.

Re: Nuitka Progress in 2015 – Python Compiler

#55

Post by _yy » Fri, Feb 05, 2016, 1:51 PM UTC

jerf wrote: post #48

_yy wrote: post #12

Earlier quoted context omitted.

Remember that critical Go security update? Usual procedure - update the shared library, restart affected services. Go - recompile everything.

Yeah, but... that's not really the "usual procedure" though. Nobody who knows what they are doing literally downloads openssl manually, compiles the new shared library, manually installs it, and manually restarts the affected services, on the grounds that if you do that you have just proved you don't know what you are doing. (Most charitably, you're doing a "Linux From Scratch" for educational purposes, but that's ju…

No, you update the shared library using your distribution's package manager and then restart the affected services using one of the small scripts for that purpose.

What's the issue with that?