JuliaApps proposal

Hi everyone,

I’ve put JuliaApps for your consideration: https://github.com/sadit/JuliaApps. This tool aims to simplify sharing Julia packages/applications with people who don’t know the Julia programming language. Most of the work involves handling isolated environments.

It is a simple bash-based workaround (until juliac is ready) to run Julia packages as commands/applications. The core idea is to clone Julia package repositories, instantiate them, and run them using the appropriate environments. It uses an entry point that handles the command line arguments (currently, it uses Comonicon.jl’s command_main for this).

Installing

Clone the repository; the unique script is japps. Give execution permissions chmod +x japps; copy japps to some directory in your executable path. It may be a good idea to put it in the same directory than juliaup.

This procedure only works for unix based systems

Usage

The idea is then to install packages having entry points, for instance:

japps install https://github.com/sadit/XGrep.jl

this will clone the XGrep repo, instantiate it, and try to precompile it.

then, it can be used as follows:

japps run XGrep -h
bash> japps --help

Install and run julia packages from command line easily

 usage: ./japps <commands> args...

 commands: run install uninstall update list help
...

Packages not need to be in some registry to be installed. Updates are basically git pull on the repository, followed by instantiation and precompiling.

It is also posible to make that japps run XGrep becomes just XGrep using symbolic links to japps and storing these symbolic links in the same directory where japps is installed.

Comonicon.jl is faster than ParseArgs.jl; however, it is still slow than what most of us really want.

This is a work-in-progress and any comment, idea, pull-requests are welcome.

Best,
Eric

7 Likes

Cool! I might have to test this out soon.

Have you seen this - any thoughts comparing the two approaches? GitHub - LilithHafner/Quickdraw: Install and use Julia packages with a single command on systems that may or may not already have Julia.

1 Like

Shouldn’t (by default) look for registered packages on the official releases rather than pulling the head of a git branch?

I don’t know. The tool is in an initial state, and the precise behavior is yet undecided. Perhaps accepting a second argument for the install command to retrieve a precise branch or tag is enough. I follow this way for the update command.

I guess most people don’t want application packages in the General register, e.g., name restrictions and the 3-day wait for new packages. However, applications designed for some communities surely must be in the General registry.

I didn’t know it. It seems to be a pretty similar approach.