Re: Guix Jargon File (WAS: Rethinking propagated inputs?)

[Bengt Richter <bokr@bokr.com>]

Hi Liliana,

Thank you for starting this renamed thread (as I should have done).

I think a people who are just looking at _maybe_ installing guix
should have an easy way to look up terms they haven't seen before.

But really I am more interested in promoting the idea of a snippet-quoting
convention modeled on a subset of mime email standards.

Very simple, but capable of containing and transferring anything unambiguously
(if not always with efficient transmission encodings).

We can of course already do that with signed and attached files, and we can
archive them and retrieve them, but I am interested in retrieving little pieces
and making it easy to mark things in arbitratry contexts (like this email or
a cannibal-friendly program source) so that simple snarfing utilities will be
able to extract snippet-quote info based on tags and identifiers or anything
in the headers or content per search options much like for any search engine.

This is to create a simple contribution mechanism as well as a format
for retrieval.

I have seen many code snippets from developers that are tutorial material
as well as practical how-tos for debugging and browsing guix.

Wouldn't it be nice if they were snip-quoted so that we could extract them
from mail archives in a better way than searching the raw archives, or having
to browse though treads and extract nuggets by hand?

simply:
--8<---------------cut here---------------start------------->8---
header part, ending with blank line

optional content part, encoded and delimited or referenced per header info
--8<---------------cut here---------------end--------------->8---


The header part could start with just prefixing GX- like the optional custom
header X- prefix described in mime rfcs, and we could borrow whatever was useful.

Tbc.. So called "real life" demands I postpone making a decent real example
'til later, sorry ;/

Please excuse the big top-post. I had intended to comment and edit in line ;/

BTW, I know "info guix|grep -i whatever" often gives clues about whatever, for pursuing
"C-s whatever" once inside "info guix whatever", but though concept and api indices
are great, they are not a Jargon File, and not as handy for an outsider :)

On +2021-09-05 12:50:56 +0200, Liliana Marie Prikler wrote:
> Hi,
> 
> Am Sonntag, den 05.09.2021, 11:50 +0200 schrieb Bengt Richter:
> > > We don't call things build-inputs here in Guix land, that's a no-no 
> > > :P
> > 
> > Is there an official guix jargon file or glossary file or texi file
> > or wikimedia/wiktionary/wikipedia clone on gnu.org that non-
> > cognoscenti could use to get a clue?
> AFAIK no, you more or less have to go by what the manual tells you.  As
> for why we have native-inputs and not build-inputs like other distros,
> it's because people often misclassify "build" inputs, so the definition
> actually does more harm than good.  Guix knows which files are actually
> "just used for build" by what ends up in the store, with some
> exceptions like UTF-32 encoded strings.
> 
> > Is there a thread that on that topic making any progress on making it
> > happen?
> AFAIK no.
> 
> > when someone in a thread like this offers a candidate official
> > definition, (off-topic sort of, but meta-on-topic for relevant
> > documentation) could it be snip-quoted for easy search and
> > aggregation for maintainers of official definitions and translations?
> > E.g.
> > (or actually borrow some rfc0842 or descendant so an attached file
> > generates a usuable section in mail archives that can be snarfed
> > automatically?)
> > 
> > --8<---------------cut here---------------start------------->8---
> > X-Content-type: Cadidate-guix-jargon-definition
> > Ad lib comment and metacomment ended by blank line ...
> > "> We don't call things build-inputs here in Guix land, that's a no-
> > no :P"
> > 
> > build-propagated-inputs:
> > 	<please fill in :) >
> > --8<---------------cut here---------------end--------------->8---
> When you quote someone like that out-of-context, you run a risk of
> misrepresenting what is actually stated.  What I mean, is that a
> package field called something along the lines of "build-inputs" is
> likely to confuse Guix veterans and newcomers alike, as evidenced by
> the following reply:
> 
> Am Sonntag, den 05.09.2021, 10:06 +0000 schrieb Attila Lendvai:
> > potentially worthless two cents from a newcomer's perspective:
> > 'build-time' and 'run-time' are well established concepts in the
> > wider community.
> And one, that is well misunderstood.  
> 
> > if i were reading 'linked-inputs' in a package definition, i wouldn't
> > associate it to being the set of build-time dependencies.
> That's not what linked-inputs are, though.  Take the following
> paragraph from propagated-inputs:
> 
> > For example this is necessary when packaging a C/C++ library
> > that needs headers of another library to compile, or when a
> > pkg-config file refers to another one via its ‘Requires’
> > field.
> This use case of propagated inputs explains why they need to be
> propagated when given as a (propagated-)input to a package, but not
> when given as a native input or merely existing in a profile.
> 
> The – required if we go by other systems – use case of installing
> libraries system- or user-wide is already discouraged by Guix, for it
> is not needed.  As long as we can spawn an environment, in which we can
> compile these things, it should be enough.
> 
> Note, that this is not equivalent to being a "build-time" dependency. 
> Going by Gentoo's definition "Build dependencies are used to specify
> any dependencies that are required to unpack, patch, compile, test or
> install the package", GCC is a build dependency of nearly any C program
> (and a native one at that, i.e. BDEPEND in Gentoo), but it's not a
> linked-dependency, because there are numerous ways in which other
> programs could use it without ever needing to invoke GCC.  Guix, of
> course, includes GCC as an implicit native input anyway, but that's a
> different topic.
> 
> Regards
> 

-- 
Regards,
Bengt Richter