> 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
