Hacker News Reader

Comment by Odin78 | Hacker News Reader

Noob question: What's so difficult about deploying/distributing python?

https://glyph.twistedmatrix.com/2015/09/software-you-can-use...

This should be the #1 comment/resource on this thread IMO.

I recently started writing a few Qt applications, and was strongly considering PyQt - I mean, why wouldn't I? The syntax is cleaner and I can get more work done faster using Python than C++.

I spent a few days going back and forth - comparing the performance, design time, etc of both - and in the end I'm just using Qt's JS JIT for dynamic list comprehensions and other things C++ is bad at. In the end, the fact that distributing on everything but Linux would have been reduced to having to bundle CPython in was just a deal breaker.

Linux isn't really bad for deployment, though. You can use the SUSE OBS to build packages for all the major platforms besides Arch, and since my main desktop is Arch, I'm building my software with PKGBUILD's from the get-go.

Python isn't very big (about 10-20 MB or so). What's the problem with bundling CPython?

I've written a production app in Python 3 + QT4 (PySide as opposed to PyQT) - I've bundled with cxfreed, and it's great.

Fully cross-platform.. easy to distribute. Quite nice all around.

That page dismisses py2exe, but I've used it successfully for over a decade. On unix it is as simple as:

  sudo pip install [package/repo]

Except, you often need a full compiler toolchain for all the c dependencies. Then you need to make sure you have the required header files. Then you try and deploy to a small EC2 instance and run out of RAM building lxml or similar.

If your requirements are advanced, make packages on your dev box then deploy those:

https://nylas.com/blog/packaging-deploying-python

It's an interesting idea, thanks.

this +1000

The python users I've encountered fall generally into two camps:

1) The engineer/scientist/researcher/hacker type that has python installed on their snowflake machine, and has a whole bunch of packages installed to make their flavor of snowcones. These users just want python to work, find joy in the syntax, and in general get their work done.

2) the developer that is trying to deploy the same thing to many machines. This is a pain. Often you end up with users from camp 1 trying to do this and you end up with a global python install with batteries and the kitchen sink included that is a dependency for a whole bunch of "server" apps. you update a package (because "my special snowcone needs it") and you break something else that you didn't know to test. This is a nightmare. With pip and venv it is easier to manage this, but I still see that relocatable venv is "experimental" when you read the help. IMHO, the python 3 community needs to make it very, very easy to distribute and deploy my special snowcone maker and all its dependencies to a system without python already installed, and not stomp on anybody elses snowcone maker in the process.

ATM it takes work to create a deployable artifact.

We package virtualenvs using fpm, others use Docker. But Go just spits out a single binary you can scp anywhere (the build process OTOH is more painful IMHO).

That’s why I’m highly curious about https://us.pycon.org/2016/schedule/presentation/2122/ .

Reply on news.ycombinator.com