Local/"user" installs

[subsetpark]

I'm curious what folks' opinions are about the intersection of jpm --local and jpm install.

---

Some package managers have a well-established concept of "local installs" - for instance, pip --user will install things in (I think??) ~/.local/bin, so you can add that to your path and have local binaries that sit on a local tree.

By default, jpm --local uses ./jpm_tree as its tree, including binaries. So I could add ~/jpm_tree/bin to my path and get a roughly equivalent experience.

However, there are two differences:

1. ~/jpm_tree is not a "blessed" or "standard" directory in the way that ~/.local is. It's also not hidden, which is a bit unusual - not a deal breaker, as I think Go tends to just chuck things in ~/go by default - but unusual.
2. ./jpm_tree is a relative path, not an absolute one. So if I cd to ~ and then run jpm --local install, I'll get something in my "user" jpm bin directory. But if I'm elsewhere, it'll go elsewhere.

In general, though, I'm curious as to whether folks or @bakpakin have given any thought to this as a use case in general. As an application author, I'd like to make it as convenient as possible for users to install things to some equivalent of ~/bin without having to

• use sudo
• install global dependencies

I wonder if anyone feels similarly or has any thoughts about how to do that.

[subsetpark]

Thinking on this further:

one possible solution is to say that jpm is project-only, and to write a new script which is used for managing ‘local path’ binaries. This could be as simple as a wrapper around jpm combined with a config file that sets prefix to something like ‘~/.local/jpm’.

[bakpakin]

Local here means local to a project. Per user installs of package managers isn't really something I care about, you can install jpm to use user directories rather than system directories.

[bakpakin]

The config system is more than flexible enough to set this up, adding flags for global, user local, and project local is just silly since Janet itself doesn't even load packages that way.

[pyrmont]

@bakpakin When you say you can 'install jpm to use user directories', does this mean that in the JPM config file you would use ~ to set the :modpath key to somewhere within the respective user's home directory (e.g. ~/.jpm)?

[bakpakin]

Yes, you can set up jpm to use a modpath in the a users home directory by default, but still load janet's headers and shared objects from a system directory.

[elimisteve]

Yes, you can set up jpm to use a modpath in the a users home directory by default, but still load janet's headers and shared objects from a system directory.

Great! How?

[pyrmont]

@elimisteve I believe you either need to edit the global configuration file used by JPM such that :modpath uses ~ to point to somewhere in the current user's home directory or load a separate configuration file (using a command line switch) where you define :modpath to use a specific home directory.

[elimisteve]

Thanks @pyrmont, this worked for me, partially based on http://www.unexpected-vortices.com/janet/notes.html --

mkdir -p ~/janet/{lib,bin,include}

# cd into wherever your `janet` dir is
cd janet/
make
cd build/

# I'm not sure if these are correct...
cp janet ~/janet/bin/
cp janet.h ~/janet/include/
cp -r core/ boot/ *.o *.so *.a ~/janet/lib/
cp janet_boot ~/janet/lib/
cp -r c ~/janet/lib/  # This one in particular is probably wrong

echo 'export PATH=~/janet/bin:$PATH' >> ~/.bashrc

echo '
export JANET_PATH=~/janet
export JANET_MODPATH=~/janet/lib
export JANET_LIBPATH=~/janet/lib
export JANET_BINPATH=~/janet/bin
export JANET_HEADERPATH=~/janet/include' >> ~/.bashrc

source ~/.bashrc

After that and installing jpm I was able to run

jpm install https://github.com/joy-framework/http

...and it -- apparently -- worked! :tada: Unlike before.

[elimisteve]

...it seemed to work, but now it says it can't find curl/curl.h when I try to compile https://github.com/joy-framework/http --

$ jpm install https://github.com/joy-framework/http 
Already up-to-date.
Already up-to-date.
removing /home/user/janet/lib/tester.janet
removing manifest /home/user/janet/lib/.manifests/tester.jdn
Uninstalled.
generating /home/user/janet/lib/.manifests/tester.jdn...
Installed as 'tester'.
copying src/tester.janet to /home/user/janet/lib...
compiling http.c to build/http.o...
compiling http.c to build/http.static.o...
http.c:2:23: fatal error: curl/curl.h: No such file or directory
 #include <curl/curl.h>
                       ^
compilation terminated.
error: command failed with non-zero exit code 1
  in os/execute [src/core/os.c] on line 1031
  in shell [/usr/local/lib/janet/jpm/shutil.janet] (tailcall) on line 109, column 5
  in <anonymous> [/usr/local/lib/janet/jpm/rules.janet] on line 18, column 20
  in executor [/usr/local/lib/janet/jpm/rules.janet] on line 25, column 8
  in worker [/usr/local/lib/janet/jpm/dagbuild.janet] on line 65, column 23
  in <anonymous> [/usr/local/lib/janet/jpm/dagbuild.janet] on line 21, column 43
  in pmap [/usr/local/lib/janet/jpm/dagbuild.janet] on line 26, column 7
  in pdag [/usr/local/lib/janet/jpm/dagbuild.janet] (tailcall) on line 71, column 3
  in <anonymous> [/usr/local/lib/janet/jpm/pm.janet] on line 196, column 9
  in <anonymous> [/usr/local/lib/janet/jpm/pm.janet] on line 183, column 5
  in bundle-install [/usr/local/lib/janet/jpm/pm.janet] on line 181, column 3
  in install [/usr/local/lib/janet/jpm/commands.janet] (tailcall) on line 105, column 20
  in _thunk [/usr/local/bin/jpm] (tailcall) on line -1, column -1
  in cli-main [boot.janet] on line 3644, column 17
http.c:2:23: fatal error: curl/curl.h: No such file or directory
 #include <curl/curl.h>
                       ^
compilation terminated.

[pyrmont]

@subsetpark This issue is a bit old at this point but I wanted to make a shameless plug that I nevertheless thought was relevant.

Jeep is an alternative Janet project manager I'm working on (still testing it out at the moment so it might break in unexpected ways). It sits in front of JPM and is meant to provide a few additional niceties. One of those is a new subcommand called plonk (as in 'plonk it down here').

The plonk subcommand can be run with or without a repository argument. If run with a repository argument it will download that repository to a cache (by default, $HOME/.jeep/plonk), build the executables (including dependencies) local to that cache and then copy the executables specified in that repository's project file to a binpath (by default, the system binpath).

So using Jeep you can install, say, Bagatto's bag executable to your system binpath (e.g. /usr/local/bin) like this:

$ jeep plonk https://git.sr.ht/~subsetpark/bagatto

Alternatively, you could install bag to a given path like this:

$ jeep plonk https://git.sr.ht/~subsetpark/bagatto --binpath ~/bin

The plonk subcommand only copies the executable to the binpath. Everything else done is local to the cache directory and so (hopefully) won't otherwise affect your system.