Way to make CLI in Julia?

General Usage
1

Let’s say I’ve been using the following alias:

alias julz="julia -L ~/.julia/v0.6/Julz/src/functions/utils/cli.jl -e 'cli()' --"

However I think this is a little hacky and want an actual bash cmd // like how python or npm would install it

How could I add a deps/build.jl file to make a bin executable (robustly across all systems)

2

also, the cli file in question is:

https://github.com/djsegal/Julz.jl/blob/master/src/functions/utils/cli.jl

3

On linux you just need to put #!/usr/bin/env julia at the top of the file, run chmod +x filename and add it to the system path. I assume it’s similar for macs, but I have no idea for windows.

In your case you will also need to add the cli() function call to the file itself so that the file is a self-contained script.

4

Is there a way to automize this?

I’d prefer to not have people have to:

  • run chmod on a file and
  • add things to their PATH (in a bash profile)
5

To me, these are safeguards that I would not want a package to override.

1 Like
6

Do you have an idea around it?

If I do brew install node, I want to be able to use the node command from the terminal immediately

7

Are you intending to provide this as a registered Julia package (via METADATA)? If so, that’s the key difference - I don’t expect Pkg.install or Pkg.build to do anything to my global environment, and I’d be TICKED if some package I installed started installing executables outside the environment or altering my path.

If this is intended to be installed via some other means, then you could do what homebrew does; namely, create a separate script and make that script download and chmod the file. Since PATH environments are widely different, there’s not a whole lot you can do about that except try to write things into /usr/local/ somewhere.

8

What I had in mind was that most of those changes would be checked into git and wouldn’t run in your build.jl. The only thing that would happen in build.jl is that you invite the user to add a given directory to their path.

9

BinDeps already does this if you use, for example, apt to grab dependencies.

Edit: not arguing this is good behavior, just pointing out that it is actually common in the current package ecosystem

10

Right; my experience is primarily on OSX, which uses a “sandboxed” (not really, but different install root) version of homebrew.

Does this imply that you need root to install BinDeps packages on Linux?

11

Sometimes yes, but the process of asking for the sudo password hasn’t worked for some time now…

12

I guess this means that, in general, any BinDeps-using package is going to be a no-go (or at least a bureaucratic hassle) on most HPCs that provide even a modicum of security.

13

This is pretty off-topic, but if the package provides a “from source” build option, that doesn’t need root, but I believe the system package manager takes precedence. You need to manually comment-out the provides(AptGet, ...) line in build.jl if you want to prevent the package from preferring the system package manager.

1 Like
14

Just following up on this, what’s the best way to distribute Julia CLI tools then?

This seems like a thing that more people are going to want over time

1 Like
15

For *nix, I’d suggest either installation instructions that include “download, chmod +x, move to directory in path”, or a shell script that does this that gets executed by whatever package manager / distribution mechanism that is used to install the tool.

16

It just seems like there should be an easier way.

Making a cli in python was one of the simplest things I ever did:

Also, users are a notoriously unfaithful bunch.

Each unusual step you give them leads to sizable acquisition drop-offs

2 Likes
17

I’m not quite sure what problem you’re trying to solve here, then. At some point in order to use a CLI tool one needs an executable to be installed in a place that the user can run it. It sounded to me like you didn’t have that, which is what my previous comment attempted to address.

This problem isn’t unique to Julia; it’s part of the installation process for every downloaded executable ever.

If you could enumerate specifically what you’re trying to do, and what problems you’re running into, maybe we could help find a solution.

18

Summarizing:

  • There is an existing CLI file that has an alias
    • alias julz="julia -L ~/.julia/v0.6/Julz/src/functions/utils/cli.jl -e 'cli()' --"
  • In order to move from an alias to an executable, it needs to be distributed through something like apt-get or brew
  • I’m unclear on how to package a Julia package in a format that would get approved by either of those projects (e.g. brew) where the executable is just that alias in a bash script

Are there other projects that have made Julia executables?

How do people deal with the need for people to have Julia and do a Pkg.clone before the script can be run?

I’m aware this problem is not unique to Julia.

I just don’t know how to accomplish it in as few steps as possible (without reinventing 10 wheels)

1 Like
19

In order to move from an alias to an executable, it needs to be distributed through something like apt-get or brew

Why do you need to do this at all? Is it easier for folks to type apt-get install julz-cli (or whatever you’re calling it, and then making sure you’ve got both apt and brew installers, and then that just handles folks who have ubuntu and osx with homebrew installed) than to type curl -L https://mysite.com/install_tool.sh | bash (where install_tool.sh does the lifting)?

1 Like
20

This is getting close to the final answer.

I just don’t know how to make a debian package and submit it to apt-get.

If you make it a stand-alone project that just has:

julz () {
  julia -L ~/.julia/v0.6/Julz/src/functions/utils/cli.jl -e 'cli()' -- "$@"
}

Will it even get accepted?

Do you have any docs or existing Julia packages that do this?