Closed subsetpark closed 2 years ago
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’.
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.
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.
@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
)?
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.
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?
@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.
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.
...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.
@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.
I'm curious what folks' opinions are about the intersection of
jpm --local
andjpm 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:
~/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../jpm_tree
is a relative path, not an absolute one. So if I cd to~
and then runjpm --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 tosudo
I wonder if anyone feels similarly or has any thoughts about how to do that.