Re: [Jgeneral] Thought experiment -- pacman
On Fri, Aug 26, 2022 at 9:57 AM chris burke wrote: > 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? Hmm... At the very least, I'd want to preserve the caption and description, because that's what's displayed in pacman's UI. But we do need the repo, also. It's probably not a problem to store the information in ~addons/config. Thanks, -- Raul -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] Thought experiment -- pacman
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 wrote: > > On Fri, Aug 26, 2022 at 1:22 AM 'Viktor Grigorov' via General > 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
Re: [Jgeneral] Thought experiment -- pacman
On Fri, Aug 26, 2022 at 1:22 AM 'Viktor Grigorov' via General 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
Re: [Jgeneral] Thought experiment -- pacman
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. 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. Aug 26, 2022, 08:02 by rauldmil...@gmail.com: > On Thu, Aug 25, 2022 at 10:17 PM 'Viktor Grigorov' via General > wrote: > >> github is a monopoly, but not the sole code hosting website. Allowing for >> any remote or local repository would be more prudent. >> > > Sure... hmm... > > Currently, github is the only repo supported by pacman. > > Perhaps it would be wise to first support some second hosting repo? > Call it "Step 0" ... > > But, which one? > > (Seems to me that github is almost an anti-monopoly -- in the sense > that competitors tend to distinguish themselves by being more > difficult and/or more costly to use.) > > -- > 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
Re: [Jgeneral] Thought experiment -- pacman
On Thu, Aug 25, 2022 at 10:17 PM 'Viktor Grigorov' via General wrote: > github is a monopoly, but not the sole code hosting website. Allowing for any > remote or local repository would be more prudent. Sure... hmm... Currently, github is the only repo supported by pacman. Perhaps it would be wise to first support some second hosting repo? Call it "Step 0" ... But, which one? (Seems to me that github is almost an anti-monopoly -- in the sense that competitors tend to distinguish themselves by being more difficult and/or more costly to use.) -- Raul -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] Thought experiment -- pacman
github is a monopoly, but not the sole code hosting website. Allowing for any remote or local repository would be more prudent. Package updating would be nice IF doing the install doen't overwrite file (and clear dir beforehand). Aug 26, 2022, 04:03 by rauldmil...@gmail.com: > Currently, we can install packages from github, using the pacman's > install, but there's no tracking of where they came from, so there's > no support for updating them. > > So, I've been thinking about maintaining a GITHUBADDONS_jpacman_ which > is structured like ADDONS_jpacman_ (five columns: FOLDER, VERSION, > depends, CAPTION, DESCRIPTION). These five columns all would come from > the package's manifest.ijs (except that depends would be > (;(,',',])each/cutLF DEPENDS) because DEPENDS is newline delimited and > we want commas for ADDONS). > > And, either install_gitrepo_jpacman_ or readpackage_jpacman_ (or > perhaps some other routine) would ensure that the manifest contents > were stored in this GITHUBADDONS which, in turn, would be stored some > place like ~/user/config/github-addons.txt > > That's step 1. > > Step 2 would be to add UI support for updating these addons. > > I guess, for this, we would need to re-download each manifest for each > installed github addon, and we'd want a (perhaps optional) 'github' > tab in the pacman ui, listing these addons. > > Later on, we might want an official prebuilt github-addons.txt and > only store in the user's config the entries absent from that. But that > would be more of an obstacle than a help, for step 2. > > But before I get too carried away here... how does this sound? Am I > overlooking critical issues? > > 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
[Jgeneral] Thought experiment -- pacman
Currently, we can install packages from github, using the pacman's install, but there's no tracking of where they came from, so there's no support for updating them. So, I've been thinking about maintaining a GITHUBADDONS_jpacman_ which is structured like ADDONS_jpacman_ (five columns: FOLDER, VERSION, depends, CAPTION, DESCRIPTION). These five columns all would come from the package's manifest.ijs (except that depends would be (;(,',',])each/cutLF DEPENDS) because DEPENDS is newline delimited and we want commas for ADDONS). And, either install_gitrepo_jpacman_ or readpackage_jpacman_ (or perhaps some other routine) would ensure that the manifest contents were stored in this GITHUBADDONS which, in turn, would be stored some place like ~/user/config/github-addons.txt That's step 1. Step 2 would be to add UI support for updating these addons. I guess, for this, we would need to re-download each manifest for each installed github addon, and we'd want a (perhaps optional) 'github' tab in the pacman ui, listing these addons. Later on, we might want an official prebuilt github-addons.txt and only store in the user's config the entries absent from that. But that would be more of an obstacle than a help, for step 2. But before I get too carried away here... how does this sound? Am I overlooking critical issues? Thanks, -- Raul -- For information about J forums see http://www.jsoftware.com/forums.htm
