Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add snapcraft packaging #4852
Adds snapcraft build configuration and command to run an in-snap Python 2 runtime. This allows MXNet to be used either by calling "/snap/bin/mxnet.python" or by adding the following to your environment and using your system's python:
The snap can be build with "snapcraft snap" on Ubuntu 16.04 or later. Use "snapcraft cleanbuild" to build it in an LXC container instead.
@piiswrong I've been looking at that mxnet-distro repo, trying to understand where and how you want the snapcraft integrated. Do you simply want the files in this PR submitted there (with modification to paths) or do you want it to be fully integrated into the Travis configuration so that it will create and publish the snap after the Travis build (a more involved process than this PR)?
Scala and R can either be bundled into the same .snap as the python library, or we can split this into 3 different language-specific snaps, depending on how desirable small packages are and how common it is for a user to need support for more than one language.
My understanding is that mxnet can be built to use GPU if the build host supports it. Because the use-case for this snap will have the code being executed normally (i.e. without a sandbox) there should be nothing stopping it from detecting and using a GPU at runtime.
Mar 23, 2017
6 of 9 checks passed
Do you mean binary snap packages? If so, you can use https://build.snapcraft.io to create them, triggered by commits here. It's like Travis, only made specifically for creating and publishing snaps.
The "snap install" command doesn't currently give any information about GPU. We could have two separate packages, or include both sets of binaries in the same package
build.snapcraft.io will default to building on multiple arches (x86_64, armhf and arm64 I think). It will publish them to an "edge" channel in the store that is the equivalent of daily builds, and only seen by people who specifically ask for the bleeding edge packages. They can then be tested and promoted into "beta" and "stable" channels. By default users will only see the versions published into "stable"