I again think you overstate the problem. An addon goes into a well-defined folder, so we can forget about them.
Userfolders allow more than one developer to work on the same source, even where the source may be stored in different locations on different machines - but this is a development issue. Once the app is developed, the usual way to distribute it is to agree on a deployment directory, then zip everything up and send out the zip. Userfolders are not relevant here. On Fri, May 19, 2023 at 10:30 AM Raul Miller <rauldmil...@gmail.com> wrote: > > My take here is that at least some of the time during development, > multiple instances of the petal project would need to exist on > developer machines. > > Probably each developer would set up a user key (perhaps > control-shift-P) to load the primary development copy of the > application. > > In messages, we typically refer to files using abbreviated paths > relative to the project root. > > The developers should not have to know the absolute path of the > project on other developer machines. That information is subject to > change and developers are likely to have multiple copies of the app > deployed (for testing and maintenance purposes). > > My plan was to support this by allowing the project to be stored > anywhere (including under ~addons/), with recursive loads able to use > the ~dir/ prefix which is agnostic to project location. > > So, for example, if there's a bug in the addon, the developer could > have a test instance of that version of the addon for debugging > purposes without having to give up any incomplete work on a potential > next major release. No special tooling or configuration needed here. > > (That said, perhaps it would be better to name this shortcut ~loading/ > rather than ~dir/ to better convey its role.) > > Anyways... the problem I see with ~Petal in UserFolders_j_ is that > that becomes a complication at deployment time. And that's going to be > a problem for anyone who wants to use J to develop software which > other people would use. > > Thanks, > > -- > Raul > > On Fri, May 19, 2023 at 9:57 AM chris burke <cbu...@jsoftware.com> wrote: > > > > If Petal is an addon, then it will be found in ~addons/alice/petal. > > > > More realistically, suppose Petal is a new app being developed that > > might eventually end up as an addon. At least for now, each > > collaborator will define ~Petal appropriately for their system layout. > > > > Normally, the collaborators will have no interest in where each stores > > their copy of the Petal source. But suppose that for whatever reason, > > they decide to tell each other. In what way would this information be > > of use? Note, I am not thinking of pathological examples, but rather > > of ordinary examples where knowing where Petal is stored on each > > machine might be of use. Are there non-trivial examples where such > > information would be helpful? Remember that the information is readily > > obtained from jpath '~Petal'. > > > > On Fri, May 19, 2023 at 8:55 AM Raul Miller <rauldmil...@gmail.com> wrote: > > > > > > 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 <cbu...@jsoftware.com> 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 <rauldmil...@gmail.com> > > > > 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 <bbill....@gmail.com> 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 <bbill....@gmail.com> 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 > > > > > > > <rauldmil...@gmail.com> 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 > > > > > > >> <cbu...@jsoftware.com> 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 > > > > > > >> > <rauldmil...@gmail.com> > > > > > > >> 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 > > ---------------------------------------------------------------------- > > 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
