>ven. 08 août 2025 at 10:56, Maxim Cournoyer <maxim.courno...@gmail.com> wrote:
>> To facilitate the upcoming maintenance of this (increasingly complex) >> ecosystem, I think we should probably try to organise these packages. At >> a minimum, we might: >> >> - UxlFoundation (uxlfoundation.org) > > I'm not sure I like naming modules by the organization producing the > packages -- it sounds a bit like advertising at the level of the Guix > API :-). Which we've been happy to do with GNU packages but less so with > other packages. Let’s call it oneapi (uxlfoundation is the github org). > I personally prefer the current state where things sorted by > areas/topographically; this is what we've historically done and it makes > for a nicer API in my opinion: (gnu packages electronics) is a good > example of a recent one that fit that. Sometimes sorting feels like random. Electronics.scm is a good example: we have electronics packages in "engineering" (and somewhere else) which is a drop-in container; "fpga" concerns more than fpgas, and should be merged with "electronics" ... This is not a big deal, as it concerns mainly leaf packages. With closely related packages, I’m afraid this keeps new contributors away. Regarding oneapi: we have onednn in machine-learning.scm; onetbb under ... tbb.scm. We even have sycl (adaptivecpp) under ... sycl.scm. Onedal, oneccl, onemath (all part of uxlfoundation), where should they go ? > [...] > >> - Rocm (rocm.docs.amd.com) >> >> + llvm - llvm-for-rocm - in (gnu packages rocm) >> + xxx - xxx - in (gnu packages rocm) > > Note that llvm-for-rocm is a variant of llvm that inherits from it > (IIRC), so can't be moved elsewehere without introducing cyclic > dependencies at the top level, as the inherit field is not delayed or > thunked (info "(guix) Cyclic Module Dependencies"). You’re right. > Note also that even if a single org packages are spread in multiple > modules, that's easy to work around with a per-team manifest that can be > placed under etc/teams/ with the listing of the revelant packages to be > maintained by the team. To me, this is error prone. Random contributors need to know about a lot of modules, packages and have a rather good global overview about how all things are organised and dependencies among packages. For example: llvm-for-rocm (in llvm.scm) is based (now) on llvm-19; adaptivecpp (in sycl.scm) uses rocm-opencl-runtime (in roc.scm), spirv-headers (in vulkan.scm) ... and clang/llvm-15. All of that is related to each other. Spreading related packages in different modules complicates things, unless you’re already familiar with the whole organization. A random contributor might feel overwhelmed,chances to do it wrong are considerable. My proposal goes with keeping all rocm related under rocm.scm; all vulkan related under vulkan.scm, etc. And all uxlfoundation related packages under oneapi.scm. This reduces the spread and eases contributing, IMO. C.
signature.asc
Description: PGP signature
