On Fri, Aug 26, 2022 at 1:22 AM 'Viktor Grigorov' via General <[email protected]> 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
