I agree it makes sense to support more hosting repos. The relevant pacman code is under https://github.com/jsoftware/base9, in particular see gitrepo.ijs.
Perhaps the info in the proposed ~user/config/user-addons.txt would be better in ~addons/config, either as a new file or extra info in addins.txt? On Fri, Aug 26, 2022 at 5:28 AM Raul Miller <rauldmil...@gmail.com> wrote: > > On Fri, Aug 26, 2022 at 1:22 AM 'Viktor Grigorov' via General > <gene...@jsoftware.com> wrote: > > There's bitbucket.org, codeberg.org, gitlab.com, sr.ht, gitea.io, among > > others. (They don't also arguably illegaly feed your code to their > > commercial products.) There can't not exist some way to test whether or not > > a URI points to a repository. Most, if not all use have a suffix of > > 'username/repositoryname', you could make a fall-through case of github if > > no explicit domain is given. > > I'm not too worried about J addons "appearing illegally in commercial > products" as a risk model (at least, not this year, for a variety of > reasons). I'm far more concerned with the availability of at least one > J addon hosted publicly at the repository. > > (I guess adding support for private repositories might be worth > doing... But using the repository's shell tools should be adequate if > you're at that level of involvement with a project. And ironically > that would be a much bigger project than what I've proposed here.) > > > That said, one could easily manage updates with a short shell script: go to > > plugins dir, sequentially cd and pull --rebase. I don't use any myself, so > > I'm unfamilar with what pacman can do exclusively. My 2c. > > pacman uses the repository's web interface and the "raw" url structure > to retrieve the files (starting with manifest.ijs), bypassing git's > shell command tools entirely. > > An addon, in this context, is the repository identifier (which is, in > essence, the "protocol" because this defines the url structure), the > user's account name (which becomes the name of the containing > directory under J's addons directory), and the project name (which > becomes the directory name within that account name directory). The > addon must have a manifest.ijs at the top level of the project, and > this identifies all other files within the addon (which are the only > files retrieved by J -- so, no git history). See also: > https://code.jsoftware.com/wiki/Addons/Developers_Guide > > However, as you say, bypassing pacman altogether and installing the > archive outside of J -- including using git itself -- would be an > option for people inclined to work that way. This approach might be > convenient when *developing* an addon (though it has the minor > downside of requiring a second install of J if the J developer wants > to test that pacman installs the package properly -- that said... > personally, I like organizing my primary copies of hosted repositories > in a directory named for the repository hosting site). > > Anyways... I guess the focus I'm taking from all of this is that > perhaps my proposed user addons.txt should be named "user-addons.txt" > to make it independent from the repository name, in the event that > people are interested in hosting J addons in some other repository. > > Also, expanding the current pacman github support should be relatively > straightforward. Basically, it would be adding another repo with a > slightly different raw url structure. > > 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
