guidelines for package names (namespaces?)

guidelines for package names (namespaces?)

[Andy Tai]

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.

Re: guidelines for package names (namespaces?)

[John Kehayias]

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

Re: guidelines for package names (namespaces?)

[Csepp]

John Kehayias <john.kehayias@protonmail.com> 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?)

[Andreas Enge]

Am Wed, Jul 05, 2023 at 08:19:48PM +0000 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?)

[Attila Lendvai]

> 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?)

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi,

On Thu, Jul 6, 2023 at 2:29 AM Attila Lendvai <attila@lendvai.name> 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?)

[Juliana Sims]

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 <package>` 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