Labs also have dependencies that are checked when loaded, see
http://www.jsoftware.com/jwiki/Labs/File%20Layout#Dependencies

On 6 July 2015 at 09:14, Raul Miller <[email protected]> wrote:

> What about labs?
>
> Thanks,
>
> --
> Raul
>
>
> On Mon, Jul 6, 2015 at 7:42 AM, chris burke <[email protected]> wrote:
> >> Now... there are of course arguments against automatically installing
> > software. What if J isn't internet connected?
> >
> > Each package manifest should include its dependencies in the DEPENDS
> noun,
> > and these will be installed if necessary when the package is installed.
> It
> > would be better that these were defined correctly than trying to install
> > software automatically when a package is loaded.
> >
> > On 6 July 2015 at 02:02, Raul Miller <[email protected]> wrote:
> >
> >> It seems like we are approaching a consistent set of naming
> >> conventions for pacman addons.
> >>
> >> However, there are still some inconsistencies - where one part of the
> >> system uses a different set of conventions from other parts of the
> >> system and/or where one part of the system uses data structures which
> >> are inconsistent with other parts of the system.
> >>
> >> For example, currently, the definition of require is:
> >>
> >> 3 : 0
> >> fls=. Loaded_j_ -.~ getscripts_j_ y
> >> if. # fls do. load fls else. empty'' end.
> >> )
> >>
> >> If I change this to:
> >>
> >> require=: 3 :0
> >>   try.
> >>     fls=. Loaded_j_ -.~ getscripts_j_ y
> >>     if. # fls do. load fls else. empty'' end.
> >>   catch.
> >>     require'pacman'
> >>     'update' jpkg ''
> >>     'install' jpkg y
> >>     load y
> >>   end.
> >> )
> >>
> >> It sort of works, but not completely:
> >>
> >>    require'debug/dissect stats'
> >> not found: /applications/j64-804/addons/debug/dissect/dissect.ijs
> >> Updating server catalog...
> >> Installing 2 packages
> >> Downloading debug/dissect...
> >> Installing debug/dissect...
> >> Downloading graphics/gl2...
> >> Installing graphics/gl2...
> >> Done.
> >> not found: /applications/j64-804/addons/stats/base/base.ijs
> >> |file name error: script
> >> |       0!:0 y[4!:55<'y'
> >>
> >> Now... there are of course arguments against automatically installing
> >> software. What if J isn't internet connected? What if the user or the
> >> machine or the account doesn't have permission to install? So there
> >> are arguments against this specific implementation.
> >>
> >> But at the same time, it seems as if the shorthands used in one one
> >> context (require or install) should be valid in the other context.
> >> Maybe not in this J release, but at some point...
> >>
> >> This suggests that fullname_j_ defined in system/main/stdlib.ijs and
> >> install_addon_jpacman_ and install_console_jpacman_ defined in
> >> system/util/pacman.ijs should converge.
> >>
> >> It seems like the easiest way to accomplish this would be to modify
> >> readlocal_jpacman_ by adding the following statement:
> >>
> >> ZIPS_jpacman_=: (fullname_j_&.> {."1 ZIPS_jpacman_) 0}"_1 ZIPS_jpacman_
> >>
> >> And then use fullname_j_ when indexing into that first column of ZIPS.
> >>
> >> I have not fully investigated the implications of this kind of change.
> >> Perhaps it would also be that the second column of PKGDATA_jpacman_
> >> should also be changed in this way?
> >>
> >> And, of course, keywords such as 'all' would still need to be respected.
> >>
> >> Still, the overhead seems slight (compared to the overhead of
> >> downloading and unpacking the packages), and the conceptualization
> >> seems consistent.
> >>
> >> But would this break anything? (Does anything rely on exporting ZIPS
> >> or PKGDATA? Do we have an appropriate inverse for fullname_j_?
> >>
> >> Thoughts?
> >>
> >> 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

Reply via email to