Hi, Cayetano Santos <csant...@inventati.org> writes:
>>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. I think we agree that topographically sorting packages makes sense; that doesn't mean the current sorting is perfect, there are many places it could be improved, and what you are proposing makes sense. The '(gnu packages electronics)' one was introduced recently so it's expected to find electronics packages somewhere else still. > 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 ? If they all do very different tasks, it makes sense to be that they are grouped with packages that do similar tasks rather than the organization producing the packages. That said, if we already have many unique per-package modules for packages from that org, then I agree having a 'oneapi' module to group them together would be nicer. [...] > 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. It's a bit more complicated, but I think it's still worthwhile in most cases (maybe not the one at hand though). The Apache project probably has a few hundreds of packages, it wouldn't make much organizational sense to put group them all under (gnu packages apache), even less for a (gnu packages gnu) package for GNU 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. I disagree that simply having inter-modules dependencies is a (problematic) source of complexity. It's normal and expected in Guix. Most of the time you can focus on the leaf package without caring about the transitive dependencies much. > My proposal goes with keeping all rocm related under rocm.scm; all > vulkan related under vulkan.scm, etc. That proposal makes sense to me. > And all uxlfoundation related packages under oneapi.scm. This reduces > the spread and eases contributing, IMO. I don't know if it'd ease contributing, but a oneapi modules sounds better than a few disparate per-package modules for packages from that family/project. -- Thanks, Maxim
