unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Nikita Gillmann <nikita@n0.is>
To: Josh Marshall <joshua.r.marshall.1991@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Should guix track package aliases?
Date: Sun, 10 May 2020 11:10:55 +0200	[thread overview]
Message-ID: <20200510091055.pdceleubjg76fsr6@hex> (raw)
In-Reply-To: <CAFkJGReHu-NTVkFSvQnzG-YOkJa8J+x5KdOxQZkKe1uej4QVnw@mail.gmail.com>

Hi,

I'm not sure if that's something guix needs to be aware of.
If the name differs very much and guix naming conventions differ plus it
can not be found through any of the fields, it makes sense. But you
probably don't want to track the different conventions used by various
package managers as it is not really low-effort without knowing written
and unwritten conventions and where to find them.

just my initial thoughts on this, knowing a fair share of PMs.

Josh Marshall transcribed 2.5K bytes:
> I'm starting to collect software that needs packaging, and one thing I'm
> running into is that naming conventions between the source project, various
> distros, and guix itself have some drift.  Something which seems low effort
> but would ease translating between various nomenclatures would be to track
> package aliases.  These would be non-canonical in guix, but like shells
> sometimes making suggestions as to what program you might have intended to
> type would make life easier.
> 
> The approach which I think makes the most sense is to add an optional but
> encouraged field in package definitions which takes a list of alternative
> package names.  When using `guix search` this field could also be
> evaluated, and when `guix package -i` is invoked and the target does not
> exist, these aliases could be searched through for similar names to the
> non-existing target and suggest the actual package they might have intended.
> 
> This appears that it could be low effort, not interfere with any commands,
> not really change the interface, and make life easier.  Anybody have any
> thoughts as to whether this would be a good idea or not?


  reply	other threads:[~2020-05-10  9:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-09 20:18 Should guix track package aliases? Josh Marshall
2020-05-10  9:10 ` Nikita Gillmann [this message]
2020-05-10  9:57 ` zimoun
2020-05-10 12:13   ` Julien Lepiller
2020-05-10 13:33     ` zimoun
2020-05-10 18:16       ` Josh Marshall
2020-05-24 19:25         ` Josh Marshall
2020-05-25 10:41           ` zimoun
2020-05-25 11:57             ` Josh Marshall
2020-05-25 12:04               ` Nicolò Balzarotti
2020-05-25 14:20                 ` Josh Marshall
2020-05-25 21:57                   ` Vincent Legoll
2020-05-25 22:30                     ` Josh Marshall
2020-05-25 23:14                       ` zimoun
2020-05-25 23:19                         ` Josh Marshall
2020-05-10 10:08 ` Vincent Legoll
2020-05-10 12:53   ` zimoun
2020-05-28 16:27     ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200510091055.pdceleubjg76fsr6@hex \
    --to=nikita@n0.is \
    --cc=guix-devel@gnu.org \
    --cc=joshua.r.marshall.1991@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).