Let's say that this is an addon. In other words, this should work:

install'github:alice/petal'
load'alice/petal'

Except, load'alice/petal' doesn't work yet, because first the user
needs to update UserFolders_j_

Why?

But, even before that, Alice needed to test that this install
procedure worked. So Alice could not have the code in
~addons/alice/petal/ -- if the code was there, Alice could not test
how installation works.

How does a fixed definition in UserFolders_j_ help here?

Thanks,

-- 
Raul

On Fri, May 19, 2023 at 7:48 AM chris burke <[email protected]> wrote:
>
> OK, suppose Alice, Bob and Chad work jointly on an app called Petal.
>
> Alice (a Mac user) installs the app in ~dev/petal.
>
> Bob (a windows user) installs the app in c:\users\bob\apps\petal
>
> Chad (a linux user) installs the app in ~/mywork/mydev/mypetal.
>
> Each user creates the path ~Petal to point to the source on their machine.
>
> IMHO, this completely solves any problem with paths.
>
> For example, each user can load and run the application with an expression 
> like
>
>    load '~Petal/run.ijs'
>
> Nothing else is needed. But if you really want to, you could get each
> source directory with an expression like:
>
>    jpath '~Petal'
>
> On Fri, May 19, 2023 at 6:33 AM Raul Miller <[email protected]> wrote:
> >
> > Indeed.
> >
> > Perhaps I should better document my proposed approach:
> >
> > My modified 'load' verb adds a 'dir' entry to the top of
> > SystemFolders_j_ while each script is being loaded, and removes the
> > first 'dir' entry from SystemFolders_j_ when the script finishes
> > loading.
> >
> > Thus when a script is being loaded, it can use the "~dir/" prefix to
> > load adjacent scripts. Without that prefix, scripts would be loaded
> > normally (which is to say, based on the working directory of the J
> > process or of course based on absolute path). Because the 'dir' entry
> > is removed from SystemFolders_j_ after the load is finished, this
> > mechanism can only be used for recursive loads.
> >
> > Because this entry is added to the top of SystemFolders_j_, each
> > recursive load would override any invoking load in the rare cases
> > where that could conflict.
> >
> > In other words: Only load / require arguments which use the "~dir/"
> > prefix from inside a script would be affected by this change.
> >
> > (And, since this is still just a proposal, 'dir' could be replaced
> > with some other name.)
> >
> > See http://www.jsoftware.com/pipermail/general/2023-May/039741.html
> > for the example implementation.
> >
> > Thanks,
> >
> > --
> > Raul
> >
> > On Fri, May 19, 2023 at 12:01 AM bill lam <[email protected]> wrote:
> > >
> > > On reflection, this can be quite complicated because a script can load
> > > other scripts recursively as mentioned in the subject line of the current
> > > email thread.
> > >
> > > On Fri, 19 May 2023 at 2:52 PM bill lam <[email protected]> wrote:
> > >
> > > > Actually I quite like this idea that loading scripts relative to the
> > > > folder of current script loaded ( not current working directory).
> > > >
> > > > I can think of an alternative is saving the folder of the last 1!:x and
> > > > then querying it using a foreign conjunction.
> > > >
> > > > On Fri, 19 May 2023 at 1:31 PM Raul Miller <[email protected]> 
> > > > wrote:
> > > >
> > > >> The problem that this would address is the complexity of figuring out
> > > >> where a project has been deployed.
> > > >>
> > > >> Yes, it's true that we can install from github. But to test that we
> > > >> have supported that we need the project installed in a different
> > > >> location.
> > > >>
> > > >> And, yes, this is entirely solvable. But it's not easily solvable,
> > > >> especially on the part of new users.
> > > >>
> > > >> Why should this be difficult?
> > > >>
> > > >> Thanks,
> > > >>
> > > >> --
> > > >> Raul
> > > >>
> > > >>
> > > >> On Thu, May 18, 2023 at 6:59 PM chris burke <[email protected]> 
> > > >> wrote:
> > > >> >
> > > >> > Suggestions like this come up from time to time, but I think they are
> > > >> > mistaken. We already have a mechanism for naming files outside
> > > >> > standard J directories, see
> > > >> > https://code.jsoftware.com/wiki/Guides/Folders_and_Projects . I don't
> > > >> > think  anything else is needed, rather any extra mechanism will add
> > > >> > unnecessary complexity.
> > > >> >
> > > >> > I'd recommend becoming thoroughly familiar with what we already have.
> > > >> Thanks!
> > > >> >
> > > >> > On Thu, May 18, 2023 at 8:59 AM Raul Miller <[email protected]>
> > > >> wrote:
> > > >> > >
> > > >> > > Quite often, we might want to work with collections of J scripts 
> > > >> > > which
> > > >> > > are outside the standard J system and user directories.
> > > >> > >
> > > >> > > It's quite possible, though obscure, to use introspection (4!:4 and
> > > >> > > 4!:3) to locate scripts relative to the currently executing script.
> > > >> > >
> > > >> > > It would probably be better to make this be an explicitly supported
> > > >> > > feature of J's load verb.
> > > >> > >
> > > >> > > Specifically, I would like to propose that while load is executing,
> > > >> > > jpath would expand ~dir/ to be the innermost referenced directory 
> > > >> > > of
> > > >> > > the currently executing load.
> > > >> > >
> > > >> > > In other words:something like
> > > >> > >
> > > >> > > load=: {{
> > > >> > >   0 load y
> > > >> > > :
> > > >> > >   fls=. getscripts_j_ y
> > > >> > >   fn=. ('script',x#'d')~
> > > >> > >   for_fl. fls do.
> > > >> > >     SystemFolders_j_=: SystemFolders_j_,~ 'dir';fpath_j_;fl
> > > >> > >     if. Displayload_j_ do. echo;fl end.
> > > >> > >     if. -. fexist fl do.
> > > >> > >       echo 'not found: ',;fl
> > > >> > >     end.
> > > >> > >     fn fl
> > > >> > >     SystemFolders_j_=: (<<<({."1 SystemFolders_j_)i.<'dir') {
> > > >> SystemFolders_j_
> > > >> > >     Loaded_j_=: ~. Loaded_j_,fl
> > > >> > >   end.
> > > >> > >   EMPTY
> > > >> > > }}
> > > >> > >
> > > >> > > Thoughts? Objections? Improvements?
> > > >> > >
> > > >> > > Thanks,
> > > >> > >
> > > >> > > --
> > > >> > > Raul
> > > >> > > ----------------------------------------------------------------------
> > > >> > > For information about J forums see
> > > >> http://www.jsoftware.com/forums.htm
> > > >> > ----------------------------------------------------------------------
> > > >> > For information about J forums see 
> > > >> > http://www.jsoftware.com/forums.htm
> > > >> ----------------------------------------------------------------------
> > > >> For information about J forums see http://www.jsoftware.com/forums.htm
> > > >>
> > > >
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to