Packaging Ruby or Python applications for distribution?

Question

Are there any good options other than the JVM for packaging Python or Ruby applications for distribution to end-users? Specifically, I'm looking for ways to be able to write and test a web-based application written in either Ruby or Python, complete with a back-end database, that I can then wrap up in a convenient set of platform-independent packages (of some type) for deployment on Windows, Linux, OS X, and FreeBSD?

Edit: What I mean by a 'web-based application' is a webapp that end-users can run on servers at their companies, providing a web service internally to their end-users. There are a lot of ways to do this on the JVM via JPython or JRuby, but I'm curious if there's a non-JVM route with alternate VMs or interpreters.

Answer 1

Try https://packager.io/, it's free if your code is public.

Quoting their site:

Distributing and installing modern web applications is a pain. We automatically package them so you don't have to. Packager.io is a service that automatically packages your application as a DEB or RPM package, for a number of target distributions.

Currently, you can package applications written in Ruby, NodeJS, or Go.

The process is as follows:

• register with your GitHub account.
• enable one of your applications that you want to package.
• every time you push new code to your GitHub repository, a build is launched on our servers. You can also manually launch a build from the user interface.
• during the build process, your code is fetched, and runs through a list of buildpacks, which take care of fetching all the dependencies required by your application, and then a DEB or RPM package is generated, and hosted in your own APT or YUM repository.
• you can now log-in on your servers, and install your application with a simple apt-get install or yum install.

Usage is like this

my-app run ruby -v
my-app run rake db:migrate
my-app run console
#Inspect your application's logs:    
my-app logs
#Set configuration variables for your application:
my-app config:set DATABASE_URL=...
#Start/Stop/Restart the application, in a distribution-independent way:
my-app start|stop|restart [web|worker]

Answer 2

You can either distribute the app as a virtual machine or create an installer that includes all dependencies, like the GitHub guys did for their on-premise version.

Answer 3

You can't strictly do this (creating a single installer/executable) in a general cross-platform way, because different platforms use different executable formats. The JVM thing is relying on having a platform-specific JVM already installed on the destination computer; if there is not one installed, then your JAR won't run unless you install a JVM in a platform-specific way. Perhaps more importantly, any third-party Python packages that rely on binary extensions will not play well with Jython unless specifically released in a Jython version, which is unusual. (I presume that a similar situation holds for Ruby packages, though I have no direct knowledge there, nor even how common it is for Ruby packages to use binary extensions....) You'd be able to use the whole range of Java libraries, but very little in the way of Python/Ruby libraries. It's also worth noting that the JVM versions of languages tend to lag behind the standard version, offering fewer language features and less-frequent bugfixes.

If your code is pure Python, then it's already cross-platform as long as the destination machine already has Python installed, just as Java is... but at least in Windows, it's rather less safe to assume that Python is installed than to assume that Java is installed. The third-party elements (database, etc) are likely to be platform-specific binaries, too. User expectations about what's a reasonable installation process vary considerably across platforms, too -- if your app uses third-party libraries or tools, you'd better include all of them for Windows users, but *nix users tend to be more tolerant of downloading dependencies. (However, expectations for that to be handled automatically by a package manager are growing...)

Really, if this is a large-ish application stack and you want to be able to have a drop-in bundle that can be deployed on almost any server, the easiest route would probably be to distribute it as a complete VMWare virtual machine -- the player software is free (for at least Windows and *nix, but I presume for Mac as well), and it allows you to create a dedicated Linux/BSD system that's already fully configured specifically for your application. (I say Linux/BSD because then you don't need to worry about OS licensing fees...)

(If it's a smaller application that you want to allow to run on a client's existing webserver, then I suspect that cross-OS compatibility will be less of a concern than cross-webserver compatibility -- while Apache does have a Windows version, the vast majority of Windows webservers run IIS, and having a single package distribution (or even single version of your application) that plays well with both of those webservers is likely to be impractical.)

Answer 4

I'm not sure I understand you here. You want to create a web-based application that you want to ship to end-users? I'm not sure how to interpret that:

• You want to create an app with a custom GUI that uses a network connection to grab data and stores some information locally in a database?
• You want to create a RoR/Django-type app that users can install on a webserver, and then access their own instance through the browser?

I can't speak to python, but you could use Shoes to create and package a custom GUI for Ruby (cross-platform). For packaging a webserver-based/browser-GUI app, I think the Ruby on Rails community has built some tools for that - possibly Capistrano - but then again, I don't do a lot of RoR development.

Answer 5

For Python, there's distutils, and Ars Technica had a pretty good article on packaging cross-platform PyQt applications a while back. This will get you set up so you can at least bundle things up into packages that can be deployed on multiple platforms, which is reasonable for free stuff.

I'm not sure this is really a better way to distribute things than using the JVM if you're trying to distribute proprietary code.