Post AXHXf0QoxvctFjLXUm by gothnbass@linuxrocks.online
(DIR) More posts by gothnbass@linuxrocks.online
(DIR) Post #AXHXf0QoxvctFjLXUm by gothnbass@linuxrocks.online
2023-07-02T10:49:07Z
0 likes, 1 repeats
Following on from the Quicklisp discussion that @louis initiated, I've been exploring how Syscat could build on Xach's work, and take things a few steps further. I'm developing my thoughts and prototyping here:https://www.sysc.at/display/Wikipages/ASDF_Systems_on_Syscat_-_an_introductionCaveats: it's a work in progress, and there's a bunch of documentation about the underlying software that I haven't yet deployed to that site.That said, any feedback on the thoughts and ideas would be very welcome.#CommonLisp #QuickLisp
(DIR) Post #AXHcNT1cPsmIUa0xCi by josemanuel@qoto.org
2023-07-02T12:02:11Z
0 likes, 0 repeats
@gothnbass Some ideas while reading the text: ASDF should include version information in defsystem’s :depends-on option, so potential incompatibilities would be avoided. Also, we should be able to diferentiate stable from development versions. This implies that any QL-like system should provide an easy way to get all versions of a given package and choose the right one from them. Any system that aims for discovery of packages should support and encourage (or, better yet, force) namespacing. It should also be possible to mark packages (and versions of packages) as unmaintained or buggy. Any QL-like system should have at least three components: a script, for downloading and installing packages; a website for searching, comparing and maybe hosting them; and an API that connects the two. @louis
(DIR) Post #AXHfHQCiI9wlrs0qye by gothnbass@linuxrocks.online
2023-07-02T12:34:20Z
0 likes, 0 repeats
@josemanuel @louis Good points, those; thankyou!Mind if I credit you by name on that page?- ASDF version dependencies are supported in that schema now, so we're on the same page there.- Stable vs development versions: agreed there, too. Actually, that could be a solid use-case for maintaining multiple distributions via this system.- Namespacing: exactly what do you have in mind here? I'm already separating systems from the code repos from which they could be fetched, where the repos are inherently namespaced. Do you mean at the system level, to allow for multiple different systems with the same names?- Marking repos, or entire systems, as unmaintained: good idea.- Mark as buggy: already covered by "doesn't build/pass its tests on that platform."- Separate components: that's central to the way I'm thinking about this. Syscat can provide the catalogue with an API, which is discoverable and designed for automation. That removes any coupling to a specific client.
(DIR) Post #AXHhR4ZDnBLbZAGpRg by josemanuel@qoto.org
2023-07-02T12:58:52Z
0 likes, 0 repeats
@gothnbass ASDF version dependencies are supported in that schema now, so we’re on the same page there.As far as I know, ASDF doesn’t support that yet. I may be wrong, but I haven’‘t seen it in the documentation nor in the wild. Namespacing: exactly what do you have in mind here?Most Common Lisp packages have very generic names. Namespacing would help in avoiding collitions. Again that should be done in ASDF. Mark as buggy: already covered by “doesn’t build/pass its tests on that platform.”Not exactly my idea. (I should have clarified.) I’m talking about versions of packages superseded by (serious) bugfix releases. The point is to avoid downloads with known security vulnerabilities and the like.Is a build test really needed in a system like this? I would let developers deal with that, but I’‘m not opposed to different approaches. Again, maybe I’m not understanding this through. Separate components: that’s central to the way I’m thinking about thisI completely agree. I would even remove any coupling to a specific website.@louis
(DIR) Post #AXI374VUVKP2ZzOSSO by gothnbass@linuxrocks.online
2023-07-02T17:01:40Z
0 likes, 0 repeats
@josemanuel @louis Versioned dependencies were absent for a long time but added in v3, if I'm reading the docs correctly: https://asdf.common-lisp.dev/asdf.html#Dependencies-1Admittedly, I haven't tested it in practice. However, there's been some insistence that ASDF is where versioned dependencies should be managed, so I'm happy to at least explore how to support this functionality.Agreed about namespacing: it needs to be in ASDF first.A do-not-use flag for serious bugs, especially security issues, also seems like a good idea.My thinking around build tests is less that they're needed, and more that they'd be useful.In Quicklisp, nothing's allowed unless all its tests pass on all platforms. I see the value, but I can also see the argument that it's a little *too* strict for some.What I have in mind is replacing that strict filter with a means of indicating "builds on this specific platform" and "passes all its tests on this platform" so people can filter (or not) according to their needs.
(DIR) Post #AXI68bMI9EbWcRVmqm by josemanuel@qoto.org
2023-07-02T17:35:40Z
0 likes, 0 repeats
@gothnbass Versioned dependencies were absent for a long time but added in v3, if I’m reading the docs correctlyYou’re right. At first I thought it was some recent addition, but it just turned out it was in a section where I wasn’t expecting to find it. I assumed it would’ve been mentioned when describing defsystem’s syntax and the :depends-on option. My thinking around build tests is less that they’re needed, and more that they’d be useful.My first reaction was to leave that to ASDF and the package developers, and then have some system in place to let users complain if they were given the wrong info, but that’s clearly not optimal. Build tests make much more sense. I wonder how costly would implementing that be, though.@louis
(DIR) Post #AXIHIxMAJWNhEhaoHA by jaredj@emacs.ch
2023-07-02T19:40:45Z
0 likes, 0 repeats
@josemanuel @gothnbass @louis I've only just read https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ and I'm a Lisp newb. I've watched Python packaging news for some years though. Now suitably disclaimed, my opinions follow:Versioned dependencies, dev vs. stable versions, and marking as unmaintained are things other language package repositories have needed, but other languages also usher their users onto the hamster wheel of backward incompatibility. Does the presence of these features in a package repository devalue software that is not dead but finished? Does it communicate to maintainers that backward compatibility in released software need not be preserved?For vulnerabilities, serious bugs -- or flipping it around, assertions from someone trusted that a package Works or is Safe, it ought to be possible for assertions to be made, and perhaps revoked, by people other than the package maintainer or the repository maintainer. But who am I kidding? We can't even secure our own email across organizations in a standard way, much less disembodied assertions to be read and verified by people and scripts we don't know. Sigh.To acknowledge from the beginning that there can be more than one repository, rather than one specific website, is a win. It protects users from the sort of tactic Docker tried recently.... In fact, why hasn't anyone put their language's packages on IPFS? I saw some effort a year or two ago related to container images for Kubernetes, done by Alibaba or Tencent, to put them on some kind of content-addressable, locally mirrorable storage. Maybe this idea has not happened yet because it fails to be minimally complicated.
(DIR) Post #AXIPHmZNjUsV7oj3gm by gothnbass@linuxrocks.online
2023-07-02T20:59:40Z
0 likes, 0 repeats
@jaredj @josemanuel @louis Well, when I said feedback and input are welcome, I did mean it :)I get your concerns about backward incompatibility, but the sheer stability of the base language means this is much less of an issue than in other languages.So in CL, it's about the development/feature arc of the libraries themselves. Backward incompatility (IMO) is more of an issue with discovering what the API should have been in the first place, than anything else.Software being "not dead but finished" is a pretty common thing in CL, so this is where it could be handy to have an easy way to distinguish "done" from "abandoned." Tag it as "stable" and we're good.On that note, an "obsolete" tag could be useful, e.g. for a db driver that only supports deprecated versions of the dbms.The question of who gets to make assertions about the state of a system/package is a reasonable one. This question came up in the previous discussion thread, and it's not one with a simple answer.1/2
(DIR) Post #AXIPHnNiiL8zdwHG9Q by louis@emacs.ch
2023-07-02T21:10:09Z
0 likes, 0 repeats
@gothnbass Have to say I'm getting increasingly excited about your work. However I don't feel qualified to deliver any more feedback than what has already been said (I'm just a noob with regards to CL).With regards to building, I would not see that as part of this effort beyond running some automated tests. IMHO the Racket Packages Catalog does it exactly right:https://pkgs.racket-lang.org/Go on with your work and don't try to make it right for everyone. I think you have a very good vision of what sysc.at should look like and I can't way to see it taking off! :commonlisp:@jaredj @josemanuel