Add a local package cache similar to python's pip

[tionis]

So that users can use the systemwide janet install to install user-local packages that are checked before the system-global one.
This would mainly include some new default import paths and jpm flags, I think.
This doesn't have to be default behavior but should be configurable at compile time or something like that, so that distribution packages can enable this behavior by default.

[tionis]

This was also discussed some time ago in janet-lang/jpm#17

[sogaiu]

I still don't understand the idea very well, but thought I'd also mention a context where this came up recently. The relevant quote is:

I also want to note that I didn't use the AUR package at all. I've been added as a maintainer of it and want to fix it at some time in the future. Ideally for such installs, the concept of system-global packages and user-local packages would exist

May be this could be expanded a bit on -- it wasn't obvious to me why this would be helfpul (but then a lot of things are not so obvious to me (^^; ).

My impression has been that Janet's *_PATH concepts:

binpath:    /home/user/.local/bin
modpath:    /home/user/.local/lib/janet
syspath:    /home/user/.local/lib/janet
manpath:    /home/user/.local/share/man/man1
libpath:    /home/user/.local/lib
headerpath: /home/user/.local/include/janet
buildpath:  build/

are all designed around there being a single directory per item unlike a value for the PATH environment variable which typically allows specifying multiple directories for searching.

I don't have a clear sense of what the implications might be for modifying things so that more than one location is searched (that's sort of what's being suggested, right?). I've assumed (without confirmation) that this is partly an efficiency thing and partly a simplicity thing.

May be others have better understandings.

[tionis]

I think the variables are used by jpm in the build process, though.
The exact mechanics of the env-vars is not really documented, I think.
Just adding some entries to module/paths in some way should solve the import issue, but jpm would still need a flag to install into another package tree.

[sogaiu]

I'm nott sure what's mean by "exact mechanics of the env-vars is not really documented".

May be the following bits from the janet and jpm man pages are missing some bits?

ENVIRONMENT
       JANET_PATH
              The location to look for Janet libraries.  This  is  the  only  environment
              variable  Janet  needs  to  find  native  and  source  code  modules. If no
              JANET_PATH is set, Janet will look in the default location set  at  compile
              time.

       JANET_PROFILE
              Path  to  a profile file that the interpreter will load before entering the
              REPL. This profile file will not run for scripts, though. This behavior can
              be disabled with the -R option.

       JANET_HASHSEED
              To disable randomization of Janet's PRF on start up, one can set this vari‐
              able. This can have the effect of making programs deterministic that other‐
              wise  would  depend on the random seed chosen at program start.  This vari‐
              able does nothing in the default configuration of Janet, as PRF is disabled
              by  default.  Also, JANET_REDUCED_OS cannot be defined for this variable to
              have an effect.

ENVIRONMENT
       JANET_TREE
              A convenient way to set the modpath, binpath, syspath, and  man‐
              path  all at once. This is equivalent to the --tree parameter to
              jpm.

       JANET_PATH
              The location to look for Janet libraries. This is the only envi‐
              ronment variable Janet needs to find native and source code mod‐
              ules. If no JANET_PATH is set, Janet will look  in  the  default
              location  set at compile time, which can be determined with (dyn
              :syspath)

       JANET_MODPATH
              The location that jpm will use to install libraries to. Defaults
              to  JANET_PATH,  but you could set this to a different directory
              if you want to. Doing so would let you import Janet  modules  on
              the  normal  system path (JANET_PATH or (dyn :syspath)), but in‐
              stall to a different directory. It is also a more  reliable  way
              to   install.   This  variable  is  overwritten  by  the  --mod‐
              path=/some/path if it is provided.

       JANET_HEADERPATH
              The location that jpm will look for janet header files  (janet.h
              and  janetconf.h)  that  are  used  to  build native modules and
              standalone executables. If janet.h and janetconf.h are available
              as  default includes on your system, this value is not required.
              If not provided, will default to  <jpm  script  location>/../in‐
              clude/janet.  The  --headerpath=/some/path  option will override
              this variable.

       JANET_LIBPATH
              Similar to JANET_HEADERPATH, this path is where  jpm  will  look
              for  libjanet.a  for  creating standalone executables. This does
              not need to be set on a normal install.  If not  provided,  this
              will  default  to  <jpm  script  location>/../lib.   The  --lib‐
              path=/some/path option will override this variable.

       JANET_BINPATH
              The directory where jpm will install binary scripts and executa‐
              bles   to.    Defaults   to   (dyn   :syspath)/bin   The  --bin‐
              path=/some/path will override this variable.

       JANET_BUILDPATH
              The directory where jpm  will  put  intermediate  files,  object
              code,   and  compiled  executables.   Defaults  to  ./build  The
              --buildpath=/some/path will override this variable.  You  should
             make  that  directories above this directory exist before build‐
              ing.

       JANET_PKGLIST
              The git repository URL that contains a listing of packages. This
              allows  installing  packages with short names, which is mostly a
              convenience. However, package dependencies can use short  names,
              package  listings  can be used to choose a particular set of de‐
              pendency versions for a whole project.

       JANET_GIT
              An optional path to a git executable to use to clone git  depen‐
              dencies.  By  default,  uses  "git"  on  the  current $PATH. You
              shouldn't need to set this if you have a normal install of git.

       JANET_JPM_CONFIG
              An optional path to a config file to load. This option is  over‐
              ridden by the --config-file command line option.

[tionis]

Oh I totally forgot about the man pages when looking this up 😅 ups

But a I still think a section on the notes detailing different (typical) ways on how to get a working Janet install might be useful

[sogaiu]

But a I still think a section on the notes detailing different (typical) ways on how to get a working Janet install might be useful

FWIW, at janet-lang.org, there are these bits:

• https://janet-lang.org/docs/index.html#Non-root-install-(macOS-and-Unix-like)
• https://janet-lang.org/docs/index.html#macOS-and-Unix-like

Is that the kind of thing you had in mind? Or may be something else?

[tionis]

Yes exactly, that part should be extended with a few lines on which environment variables to set.