Re: guidelines for package names (namespaces?)
Hi Andy, There are some guidelines for naming packages, as discussed in the manual: https://guix.gnu.org/en/manual/devel/en/html_node/Package-Naming.html. Ultimately, of course, the final say rests with the commiters who do or do not accept a given patch in a given state. As for namespaces, Guix packages being defined in Guile and thus in Guile modules provides namespacing in most contexts - if not operating at the command line, one need only use the correct module and reference a given package object directly. That said, last night I was just considering the potential for name conflicts. If a given `guix package -i ` command would resolve equally well to two different packages, for example, it seems the priority goes to whichever one comes first in some alphabetic comparisons - or perhaps it's by the order of channels in the channel list; I didn't investigate much more than to find out if Guix offers any manual intervention. I mused aloud about the possibility of adding a switch to specify channels in such situations and was offered the following addition to the command: `-e '(@ (my channel packages) foo)'`. This allows one to specify Scheme objects precisely. In this case, that code resolves to the package `foo` in the module `(my channel packages)`. Of course, this is not necessarily obvious or approachable to a relatively new or casual user - I had to test to understand the incantation above, and I would not have considered it without advice. All of that to say, you raise some good questions. I hope these thoughts prove useful to you in your endeavors. Best, Juli
Re: guidelines for package names (namespaces?)
Hi, On Thu, Jul 6, 2023 at 2:29 AM Attila Lendvai wrote: > > a related issue is that currently there are two parallel registries for guix > packages: > > 1) module-global variables in the guile module system > 2) the reified package registry of guix. Veering even further from Andy's topic of namespaces, please allow me to suggest that we unite those two approaches. Like Attila, I prefer the variables (except on the Guix command line). Let's provide package variables—perhaps ending with asterisks—that allow selections just like on the 'guix shell' command line. They would look like that: (ldns* #:version "1.8.3" #:output "drill") for "ldns@1.8.3:drill" Meaningful symbolic selections for the version would also be possible, like 'stable or 'latest. When the field is omitted, the caller would get the most recent stable version available. Kind regards, Felix
Re: guidelines for package names (namespaces?)
Am Wed, Jul 05, 2023 at 08:19:48PM + schrieb John Kehayias: > This is a good question and one I wonder about when packaging > sometimes. The general guideline I've seen expressed in Python land at > least (not sure if this is in the manual, but this discussion can go > towards clarifying) is that generally "libraries" get the "python-" > prefix but end user "applications" don't. I believe this is true for > Golang as well, though exceptions abound. See here: https://guix.gnu.org/de/manual/devel/en/html_node/Package-Naming.html https://guix.gnu.org/de/manual/devel/en/html_node/Python-Modules.html https://guix.gnu.org/de/manual/devel/en/html_node/Perl-Modules.html I think there are no explicit rules for other languages, but the Perl and Python approach has been taken as a general model. > a related issue is that currently there are two parallel registries for guix > packages: > 1) module-global variables in the guile module system > 2) the reified package registry of guix. > the relationship between these two is not clear, there are no formal rules, > or even guidelines. they are pretty much orthogonal. See the first link above: "Both are usually the same and correspond to the lowercase conversion of the project name chosen upstream (...)". Andreas
Re: guidelines for package names (namespaces?)
> Or GNU Guix maintainers may want to consider some type of name space > support in the package name space because I think name collisions will > be more and more likely as more packages are submitted for inclusion > in Guix. a related issue is that currently there are two parallel registries for guix packages: 1) module-global variables in the guile module system 2) the reified package registry of guix. the relationship between these two is not clear, there are no formal rules, or even guidelines. they are pretty much orthogonal. i don't have a specific issue with this, besides that it was rather confusing for me as a newcomer, and that it bothers the gut instinct of the engineer inside me. the idea of namespaces is nothing new, and has already been solved by 1). i'm not sure about all the implications, but i think picking 1) and dropping 2) is worth considering. it would automatically keep track of a namespace hierarchy, and the guix GUI would have enough data to act intelligently in situations like package-name clashes. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “All experience is a drug experience. Whether it’s mediated by our own [endogenous] drugs, or whether it’s mediated by substances that we ingest that are found in plants, cognition, consciousness, the working of the brain, it’s all a chemically mediated process. Life itself is a drug experience.” — Dennis Mckenna (1950–)
Re: guidelines for package names (namespaces?)
John Kehayias writes: > Hi Andy, > > On Mon, Jul 03, 2023 at 01:55 PM, Andy Tai wrote: > >> Hi, in Guix there seems no guidelines for package names/namespaces >> although there are conventions like Python packages prefixed with >> python-... (good). However, this does not cover cases like Gnome >> applications. For example, I submitted the original definition for >> (the GNOME terminal package) terminator, and later I tried to rename >> that gnome-terminator but that was rejected by reviewers. >> > > This is a good question and one I wonder about when packaging > sometimes. The general guideline I've seen expressed in Python land at > least (not sure if this is in the manual, but this discussion can go > towards clarifying) is that generally "libraries" get the "python-" > prefix but end user "applications" don't. I believe this is true for > Golang as well, though exceptions abound. > > The line is not necessarily clear. As an example, the "autokey" > package is written in Python and I would guess almost always used as > an application as is, but you can script with autokey itself as well. > >> Or GNU Guix maintainers may want to consider some type of name space >> support in the package name space because I think name collisions will >> be more and more likely as more packages are submitted for inclusion >> in Guix. > > I don't have any insight or knowledge on the internals here but the > general practice of a language prefix for libraries and the like has > so far worked well I think. > > John One problem: sometimes a package can be used both as a library and as a command, which means that when you try to import something that depends on it and you didn't follow the naming convention for libraries, Guix will try to import it again. I've ran into this with Yggdrasil. But this might be a missing feature of importers and not a naming issue.
Re: guidelines for package names (namespaces?)
Hi Andy, On Mon, Jul 03, 2023 at 01:55 PM, Andy Tai wrote: > Hi, in Guix there seems no guidelines for package names/namespaces > although there are conventions like Python packages prefixed with > python-... (good). However, this does not cover cases like Gnome > applications. For example, I submitted the original definition for > (the GNOME terminal package) terminator, and later I tried to rename > that gnome-terminator but that was rejected by reviewers. > This is a good question and one I wonder about when packaging sometimes. The general guideline I've seen expressed in Python land at least (not sure if this is in the manual, but this discussion can go towards clarifying) is that generally "libraries" get the "python-" prefix but end user "applications" don't. I believe this is true for Golang as well, though exceptions abound. The line is not necessarily clear. As an example, the "autokey" package is written in Python and I would guess almost always used as an application as is, but you can script with autokey itself as well. > Or GNU Guix maintainers may want to consider some type of name space > support in the package name space because I think name collisions will > be more and more likely as more packages are submitted for inclusion > in Guix. I don't have any insight or knowledge on the internals here but the general practice of a language prefix for libraries and the like has so far worked well I think. John
guidelines for package names (namespaces?)
Hi, in Guix there seems no guidelines for package names/namespaces although there are conventions like Python packages prefixed with python-... (good). However, this does not cover cases like Gnome applications. For example, I submitted the original definition for (the GNOME terminal package) terminator, and later I tried to rename that gnome-terminator but that was rejected by reviewers. Or GNU Guix maintainers may want to consider some type of name space support in the package name space because I think name collisions will be more and more likely as more packages are submitted for inclusion in Guix.
