Re: Guix Jargon File (WAS: Rethinking propagated inputs?)
Hi Jonathan, Thanks for the TXR reference, I will have to look into it. Just on the basis of the author name "Kaz Kylheku" I would check it out. I have encountered his posts 'way in the past, and they were always intelligent and interesting. (If he is older than me, I'd like to know more about his diet and habits ;-) Anyway, if you are interested in PEGs in any guix connection, I think you should look at Guile's PEG implementation and syntaxes (scheme and string/regex styles). Type "info guile" (not guix), and then "Ctrl-s Peg Parsing" which will take you to an index, and either use that link (hit Return) or hit Ctrl-s again and you should be at the beginning of some interesting reading ;-) Note that guix is built on top of guile and its infrastructure of libaries (mostly C still where they aren't scheme, UIAM, but that may be changing to include more, I'm not sure -- I am not insider enough to follow ;-) Maybe you can make a guile-txr.scm package for a txr wrapper module using foreign function or your own C extension loadable by guile scheme. Have fun! Maybe my best strategy is to see what you come up with before re-inventing things you may already be way ahead in :) Oh, if you haven't already, also check into guile's regular expressions, e.g. "info guile Ret Ctrl-s regular expressions Ret Ret" And also try guile's repl by just typing "guile Ret" and then ",help" Mvh, Bengt Richter On +2021-09-05 15:53:34 +, Jonathan McHugh wrote: > Hi Bengt, > > I believe that a collection of regular expressions for recognising starting > block and closing block for differing formats. It would for instance become > political making a choice between (say): > * -a-dangerous-pair-of-scissors--8<--ouch- ; > * an Orgmode output; a GemText block; > * somebody who uses '£' as a delimiter, > * et al. > > That way people can maintain their workflows while still having a better idea > of where other peoples blocks/citations are. > > FYI, I am looking into parsing manpages and 'cheat' style command tools to > generate Parsing Expression Grammars - so as to permit people to identify > coding, if not perform actions. Hopefully one can then identify inline > content, as well as inferences regarding when coding blocks start and stop > (let alone additional knowledge) > > I was planning on using the Lisp TXR to do so - if somebody thinks this is a > mistake please say so! If somebody would like to propose what a Guile PEG > environment should look like I can make an additional grammar. If I get > enough positive feedback I can prioritise it more for a project Im working on. > > Kind regards, > > > Jonathan McHugh > indieterminacy@libre.brussels > > September 5, 2021 4:54 PM, "Bengt Richter" wrote: > > > 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
Re: Rethinking propagated inputs?
Am Sonntag, den 05.09.2021, 22:27 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op zo 05-09-2021 om 21:37 [+0200]:
> > > > I must admit that this solution appears to have some surface
> > > > elegance, but what exactly would go in the "build" output of a
> > > > package? You mentioned pkg-config files (obviously), but those
> > > > don't suffice to actually build a package, do they?
> > >
> > > Sometimes they do suffice. The .pc files contain the "-
> > > L/.../LIB", "-I/.../include" and "-lstuff" flags needed for
> > > compilation. If the build system of the package uses pkg-config,
> > > it will use those flags, so the compiler will find the library in
> > > that case.
> > >
> > > Not sure if they always do suffice.
> >
> > Is that so? I would think the build process needs to see stuff
> > outside of its inputs for that to work, e.g. the actual header it
> > wants to include, which isn't part of "build". Am I
> > misunderstanding our sandbox requirements?
>
> The .pc file includes the absolute path to the library and include
> directories, so the output "build" with the .pc file has a reference
> to the output "out" with the libraries and include headers. More
> concretely, take the .pc from the glib package:
>
> prefix=/gnu/store/98hgv3i6hdqgiq98ldy7rkpdwhah8iq2-glib-2.62.6
> libdir=${prefix}/lib
> includedir=${prefix}/include
> [more stuff]
> Requires.private: libpcre >= 8.31
> Libs: -L${libdir} -lglib-2.0
> Libs.private: -pthread
> Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
>
> The (transitive) references of all inputs to the build process are
> included in the sandbox. In this case, if the package has the
> hypothetical glib:build among its inputs, the daemon will
> automatically make glib:out available as well in the sandbox.
And IIUC if glib had a "lib" output, glib:lib would be available in the
sandbox instead of glib:out due to the reference by glib:build? If
that's the case using #:by and "build" outputs might be a preferable
solution, if not for all packages then at least for some.
At this point the question then becomes what to name this "build"
output and what to put into it besides pkg-config stuff. Particularly
in the land of glib, there also exist typelibs, which can be used as
"build" inputs in the case of Vala or as runtime inputs in the case of
pygobject and other language bindings. Perhaps this is early
bikeshedding when we'd actually need to code up #:by, but what would be
the better approach here? Separate "build" into "pkg-config", "cmake"
(for CMake-based package discovery), "typelib" etc. or have one more or
less anonymous blob called "build"?
Greetings
Re: Rethinking propagated inputs?
Liliana Marie Prikler schreef op zo 05-09-2021 om 21:37 [+0200]:
> > > I must admit that this solution appears to have some surface
> > > elegance, but what exactly would go in the "build" output of a
> > > package? You mentioned pkg-config files (obviously), but those
> > > don't suffice to actually build a package, do they?
> >
> > Sometimes they do suffice. The .pc files contain the "-L/.../LIB",
> > "-I/.../include" and "-lstuff" flags needed for compilation. If the
> > build system of the package uses pkg-config, it will use those flags,
> > so the compiler will find the library in that case.
> >
> > Not sure if they always do suffice.
>
> Is that so? I would think the build process needs to see stuff outside
> of its inputs for that to work, e.g. the actual header it wants to
> include, which isn't part of "build". Am I misunderstanding our
> sandbox requirements?
The .pc file includes the absolute path to the library and include directories,
so the output "build" with the .pc file has a reference to the output "out"
with the libraries and include headers. More concretely, take the .pc from
the glib package:
prefix=/gnu/store/98hgv3i6hdqgiq98ldy7rkpdwhah8iq2-glib-2.62.6
libdir=${prefix}/lib
includedir=${prefix}/include
[more stuff]
Requires.private: libpcre >= 8.31
Libs: -L${libdir} -lglib-2.0
Libs.private: -pthread
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
The (transitive) references of all inputs to the build process are included
in the sandbox. In this case, if the package has the hypothetical glib:build
among its inputs, the daemon will automatically make glib:out available as well
in the sandbox.
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part
Re: Rethinking propagated inputs?
Am Sonntag, den 05.09.2021, 21:18 +0200 schrieb Maxime Devos: > [...] > [Liliana Marie Prikler schreef op zo 05-09-2021 om 18:50 [+0200]:] > > This does cause problems with language bindings though, > > e.g. pygobject, as those also propagate the package in question and > > can't be neatly separated. > > python-pygobject can just keep everything in the output "out", > and let glib and libffi be propagated by "out", no? I don't see > how this would cause trouble for language bindings. It doesn't immediately cause problems with the language bindings themselves, you are correct about that, but since packages using such bindings must by virtue of being python packages already propagate all their inputs we are back at square zero, so to speak. However, perhaps we can solve that by putting launchers in the "bin" output? > > > Now, imagine the "build" output of "zile" had glib:build in > > > propagated-inputs, using the scheme described above. Then, if > > > the "out" output of zile is installed in a profile, that doesn't > > > cause glib to appear in the profile as well, because glib is only > > > propagated for the "build" output of zile, and not for "out" > > > output of zile. > > > > > > However, if "build" is installed in the profile (e.g. because > > > someone runs "guix environment --ad-hoc zile:build various > > > compilation tools" to create an application using the zile > > > library), then the .pc becomes available in the profile. > > I must admit that this solution appears to have some surface > > elegance, but what exactly would go in the "build" output of a > > package? You mentioned pkg-config files (obviously), but those > > don't suffice to actually build a package, do they? > > Sometimes they do suffice. The .pc files contain the "-L/.../LIB", > "-I/.../include" and "-lstuff" flags needed for compilation. If the > build system of the package uses pkg-config, it will use those flags, > so the compiler will find the library in that case. > > Not sure if they always do suffice. Is that so? I would think the build process needs to see stuff outside of its inputs for that to work, e.g. the actual header it wants to include, which isn't part of "build". Am I misunderstanding our sandbox requirements? > > Would we need an extra syntax to e.g. propagate the "out" output by > > "build" (and in some cases the "lib" output instead)? > > Not if .pc files are put in "out" (or "lib" in some cases) instead of > the originally proposed "build", but otherwise, possibly? Okay, let's talk about the other things then until we can put a certain (as in "sure to be correct") answer to this question. Greetings
Re: Rethinking propagated inputs?
Liliana Marie Prikler schreef op zo 05-09-2021 om 18:50 [+0200]:
>
[...]
> > (Feel free to suggest a more concise name.)
> Since "propagated" is already given by propagated-inputs, what about
> simply having #:by?
> E.g. something like: [...]
> (define glib
> (package
> (name "glib")
> (outputs '("out" ; everything
> "bin")) ; glib-mkenums ... depends on Python
> (propagated-inputs
> `(("pcre" ,pcre #:by ("out")) ; future-proof #:by
> ("libffi" ,libffi #:by ("out")) ; have it be a list
> [...]))
That looks nice, thanks.
> I'm not sure whether we need to necessarily add a new "build" output
> for pkg-config, that'd lead to a lot of doubly-propagated includes.
> (Imagine both libffi and libffi:build etc.) I think the more
> meaningful division here would be to add "bin" or "lib" outputs to
> those packages, where we don't want propagation to continue
> indefinitely.
Putting pkg-config files into the "lib" or "out" output (together with shared
libraries)
seems reasonable to me ("lib" if the package is usually used as a binary,
but also has libaries with pkg-config files, and "out" if it is usually
used as a library).
> This does cause problems with language bindings though,
> e.g. pygobject, as those also propagate the package in question and
> can't be neatly separated.
python-pygobject can just keep everything in the output "out",
and let glib and libffi be propagated by "out", no? I don't see
how this would cause trouble for language bindings.
> > Now, imagine the "build" output of "zile" had glib:build in
> > propagated-inputs, using the scheme described above. Then, if the
> > "out" output of zile is installed in a profile, that doesn't cause
> > glib to appear in the profile as well, because glib
> > is only propagated for the "build" output of zile, and not for "out"
> > output of zile.
> >
> > However, if "build" is installed in the profile (e.g. because someone
> > runs "guix environment --ad-hoc zile:build various compilation tools"
> > to create an application using the zile library), then the .pc
> > becomes available in the profile.
> I must admit that this solution appears to have some surface elegance,
> but what exactly would go in the "build" output of a package? You
> mentioned pkg-config files (obviously), but those don't suffice to
> actually build a package, do they?
Sometimes they do suffice. The .pc files contain the "-L/.../LIB",
"-I/.../include" and "-lstuff" flags needed for compilation. If the
build system of the package uses pkg-config, it will use those flags,
so the compiler will find the library in that case.
Not sure if they always do suffice.
> Would we need an extra syntax to
> e.g. propagate the "out" output by "build" (and in some cases the "lib"
> output instead)?
Not if .pc files are put in "out" (or "lib" in some cases) instead of the
originally proposed "build", but otherwise, possibly?
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part
Re: Rethinking propagated inputs?
Hi
Am Sonntag, den 05.09.2021, 18:17 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op za 04-09-2021 om 20:24 [+0200]:
> > Hi Guix,
> >
> > some while ago we made the decision to propagate inputs, that are
> > mentioned in pkg-config files, the rationale being that those
> > propagated inputs will be needed in packages in order to
> > compile. This
> > has saved us some typing, but at a cost. For instance, it is now
> > no
> > longer possible to upgrade "zile"
>
> Zile doesn't propagate glib: it's in inputs, not propagated-inputs:
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/zile.scm#n84.
Oops, what a blunder. It turns out my mistake was
> > " and "icecat" independently, because
> > both propagate glib. "libreoffice" and "telegram-desktop", two
> > packages that have failed us loudly before, are also in that list.
>
> libreoffice doesn't propagate anything. Neither does icecat.
>
> > To
> > see what else is in here, you might want to use the following
> > snippet
> > in a guix repl:
> >
> > --8<---cut here---start->8---
> > (use-modules (guix packages)
> > (gnu packages)
> > (guix discovery)
> > (srfi srfi-1)
> > (srfi srfi-26))
> >
> > (display
> > (fold-packages
> > (lambda (p s)
> >(if (any (compose (lambda (input)
> >(and (package? input)
> > (string=? "glib" (package-name
> > input
> > cadr)
> > (package-transitive-inputs p))
> >(cons (package-name p) s)
> >s))
> > '()
> > (all-modules %default-package-module-path)))
> > --8<---cut here---end--->8---
(package-transitive-inputs p) should be (package-transitive-propagated-
inputs p). With that, telegram-desktop is still in the list, as is
gst-plugins-base (why?), rhythmbox, polari, and some others.
> > It returns more than 1400 packages – a bit less than 10% of Guix.
> > Needless to say, that's a bad thing and I think we should do
> > something about it, particularly when it comes to leaf packages,
> > that users are likely to install.
> >
> > Does anyone have an idea how we should handle propagations for the
> > sake of pkg-config? Perhaps we could add "linked-inputs", which
> > are added when building packages and environments when not using --
> > ad-hoc, but not when union-building profiles. WDYT?
>
> For packages using pkg-config, I had the following scheme in mind:
>
> A package that has .pc files puts them into a separate "build"
> output. The code handling 'propagated-inputs' is modified such that
> an entry in 'propagated-inputs' can have an additional 'propagated-
> for-output' component.
>
> (Feel free to suggest a more concise name.)
Since "propagated" is already given by propagated-inputs, what about
simply having #:by?
E.g. something like:
(define glib
(package
(name "glib")
(outputs '("out" ; everything
"bin")) ; glib-mkenums ... depends on Python
(propagated-inputs
`(("pcre" ,pcre #:by ("out")) ; future-proof #:by
("libffi" ,libffi #:by ("out")) ; have it be a list
[...]))
I'm not sure whether we need to necessarily add a new "build" output
for pkg-config, that'd lead to a lot of doubly-propagated includes.
(Imagine both libffi and libffi:build etc.) I think the more
meaningful division here would be to add "bin" or "lib" outputs to
those packages, where we don't want propagation to continue
indefinitely. This does cause problems with language bindings though,
e.g. pygobject, as those also propagate the package in question and
can't be neatly separated.
> Now, imagine the "build" output of "zile" had glib:build in
> propagated-inputs, using the scheme described above. Then, if the
> "out" output of zile is installed in a profile, that doesn't cause
> glib to appear in the profile as well, because glib
> is only propagated for the "build" output of zile, and not for "out"
> output of zile.
>
> However, if "build" is installed in the profile (e.g. because someone
> runs "guix environment --ad-hoc zile:build various compilation tools"
> to create an application using the zile library), then the .pc
> becomes available in the profile.
I must admit that this solution appears to have some surface elegance,
but what exactly would go in the "build" output of a package? You
mentioned pkg-config files (obviously), but those don't suffice to
actually build a package, do they? Would we need an extra syntax to
e.g. propagate the "out" output by "build" (and in some cases the "lib"
output instead)?
Greetings
Re: Rethinking propagated inputs?
Liliana Marie Prikler schreef op za 04-09-2021 om 20:24 [+0200]:
> Hi Guix,
>
> some while ago we made the decision to propagate inputs, that are
> mentioned in pkg-config files, the rationale being that those
> propagated inputs will be needed in packages in order to compile. This
> has saved us some typing, but at a cost. For instance, it is now no
> longer possible to upgrade "zile"
Zile doesn't propagate glib: it's in inputs, not propagated-inputs:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/zile.scm#n84.
> " and "icecat" independently, because
> both propagate glib. "libreoffice" and "telegram-desktop", two
> packages that have failed us loudly before, are also in that list.
libreoffice doesn't propagate anything. Neither does icecat.
> To
> see what else is in here, you might want to use the following snippet
> in a guix repl:
>
> --8<---cut here---start->8---
> (use-modules (guix packages)
> (gnu packages)
> (guix discovery)
> (srfi srfi-1)
> (srfi srfi-26))
>
> (display
> (fold-packages
> (lambda (p s)
>(if (any (compose (lambda (input)
>(and (package? input)
> (string=? "glib" (package-name input
> cadr)
> (package-transitive-inputs p))
>(cons (package-name p) s)
>s))
> '()
> (all-modules %default-package-module-path)))
> --8<---cut here---end--->8---
>
> It returns more than 1400 packages – a bit less than 10% of Guix.
> Needless to say, that's a bad thing and I think we should do something
> about it, particularly when it comes to leaf packages, that users are
> likely to install.
>
> Does anyone have an idea how we should handle propagations for the sake
> of pkg-config? Perhaps we could add "linked-inputs", which are added
> when building packages and environments when not using --ad-hoc, but
> not when union-building profiles. WDYT?
For packages using pkg-config, I had the following scheme in mind:
A package that has .pc files puts them into a separate "build" output.
The code handling 'propagated-inputs' is modified such that an entry in
'propagated-inputs' can have an additional 'propagated-for-output' component.
(Feel free to suggest a more concise name.)
I.e., something like:
(define glib
(package
(name "glib")
(outputs '("out" ; everything
"bin" ; glib-mkenums ... depends on Python
"build")) ; glib-2.0.pc
(propagated-inputs
`(("pcre" ,pcre #:propagate-for-output "build") ; in the
Requires.private field of glib-2.0.pc
("libffi" ,libffi #:propagate-for-output "build") ; ditto, for
gobject-2.0.pc
;; etc.
))
(native-inputs '()) ; not relevant to this e-ail
...))
Now, imagine the "build" output of "zile" had glib:build in propagated-inputs,
using the scheme described above. Then, if the "out" output of zile is
installed
in a profile, that doesn't cause glib to appear in the profile as well, because
glib
is only propagated for the "build" output of zile, and not for "out" output of
zile.
However, if "build" is installed in the profile (e.g. because someone runs
"guix environment --ad-hoc zile:build various compilation tools" to create
an application using the zile library), then the .pc becomes available in the
profile.
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part
Re: Guix Jargon File (WAS: Rethinking propagated inputs?)
Hi Bengt, I believe that a collection of regular expressions for recognising starting block and closing block for differing formats. It would for instance become political making a choice between (say): * -a-dangerous-pair-of-scissors--8<--ouch- ; * an Orgmode output; a GemText block; * somebody who uses '£' as a delimiter, * et al. That way people can maintain their workflows while still having a better idea of where other peoples blocks/citations are. FYI, I am looking into parsing manpages and 'cheat' style command tools to generate Parsing Expression Grammars - so as to permit people to identify coding, if not perform actions. Hopefully one can then identify inline content, as well as inferences regarding when coding blocks start and stop (let alone additional knowledge) I was planning on using the Lisp TXR to do so - if somebody thinks this is a mistake please say so! If somebody would like to propose what a Guile PEG environment should look like I can make an additional grammar. If I get enough positive feedback I can prioritise it more for a project Im working on. Kind regards, Jonathan McHugh indieterminacy@libre.brussels September 5, 2021 4:54 PM, "Bengt Richter" wrote: > 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:
Re: Guix Jargon File (WAS: Rethinking propagated inputs?)
Hi, Am Sonntag, den 05.09.2021, 16:54 +0200 schrieb Bengt Richter: > 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. Personally speaking, the manual and cookbook lend themselves easily to grepping (and it turns out you acknowledge that later on yourself), but of course they only reference what Guix *has*, i.e. inputs and native- inputs, not what it doesn't have, e.g. the Gentoo distinction between DEPEND and BDEPEND. > 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. Both the mailing lists and IRC channel are already archived, so what you would need to do is simply to collect the funniest quotes and publish them somewhere, perhaps with links back for context. As for tag-based lookup mechanisms, those already exist in the wild as well, you don't particularly need to reinvent the wheel. What I don't really understand from all this is for one, what purpose this Jargon file would serve, and for another, who you would want to collaborate it. For all its explanatory power, I do think a manual would be better suited most of the time if we're talking about serious definitions of important concepts. > 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? Possibly, though your particular suggestion is probably more fun if you're used to writing mail headers by hand than using a GUI client which mostly hides such things for you (I personally haven't switched to using Emacs for my mail yet, and I think integrating it with EDS or even just GOA might take some while). > 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. X- exists for a reason, so you should make that X-SOMEID-KEY, where SOMEID uniquely labels your scheme. Or who knows, maybe some scheme already exists out there and you don't need to create a new one. > 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 :) I always thought jargon files to be insider humor? Did I miss something? Like, obviously you can read them as an outsider, but you won't have a clear understanding of what is actually said by having a bunch more definitions in the back of your head. To me that sounds like learning a language with nothing but a dictionary, or worse a thesaurus.
Re: Guix Jargon File (WAS: Rethinking propagated inputs?)
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: > > > > --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 + 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
Re: Rethinking propagated inputs?
All inputs of a package are build-time, whether normal, native or propagated. The result may reference some of them, and these references are the run-time dependencies. native-inputs are usually buill-time only, because they are usually programs that are run during the build (hence the need for them to be native in a cross-build). propagated-inputs breaks this nice model by making them run-time dependencies despite the abscence of a reference. I think focusing on the name is distracting, but maybe "dependent-inputs", since this type of input would only affect the inputs of its dependents? Le 5 septembre 2021 06:06:02 GMT-04:00, Attila Lendvai a écrit : >> > What do you think of "build-propagated-inputs"? >> >> We don't call things build-inputs here in Guix land, that's a no-no :P > >potentially worthless two cents from a newcomer's perspective: >'build-time' and 'run-time' are well established concepts in the wider >community. > >if i were reading 'linked-inputs' in a package definition, i wouldn't >associate it to being the set of build-time dependencies. > >the best name, from my admittedly uninformed perspective, would be >`build-time-inputs`. > >- attila >PGP: 5D5F 45C7 DFCD 0A39 > >
Guix Jargon File (WAS: Rethinking propagated inputs?)
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: > > --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 + 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
Re: Rethinking propagated inputs?
> > What do you think of "build-propagated-inputs"? > > We don't call things build-inputs here in Guix land, that's a no-no :P potentially worthless two cents from a newcomer's perspective: 'build-time' and 'run-time' are well established concepts in the wider community. if i were reading 'linked-inputs' in a package definition, i wouldn't associate it to being the set of build-time dependencies. the best name, from my admittedly uninformed perspective, would be `build-time-inputs`. - attila PGP: 5D5F 45C7 DFCD 0A39
Re: Rethinking propagated inputs?
Hi, On +2021-09-05 09:36:30 +0200, Liliana Marie Prikler wrote: > Am Samstag, den 04.09.2021, 17:50 -0700 schrieb Sarah Morgensen: > > Hi Liliana, > > > > (Efraim, I've Cc'd you since you're working on re-doing Rust inputs.) > > > > Liliana Marie Prikler writes: > > > > > Does anyone have an idea how we should handle propagations for the > > > sake of pkg-config? Perhaps we could add "linked-inputs", which > > > are added when building packages and environments when not using -- > > > ad-hoc, but not when union-building profiles. WDYT? > > > > I know nothing about pkg-config, but such an input would help > > simplify things for Go (and I think for Rust) since many inputs need > > to be propagated only at build-time. > To be fair, I wasn't not thinking about Go and Rust, which at least on > the surface appear to have similar propagation semantics. I do however > not know whether all currently propagated inputs from those two could > be reclassified as linked-inputs. FWIW I don't think (most) Emacs, > Python or Guile packages work that way, but I do know of at least one > that would profit from having linked-inputs. > > > What do you think of "build-propagated-inputs"? > 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? Is there a thread that on that topic making any progress on making it happen? 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: --8<---cut here---end--->8--- > > (A quick search of the ML turned up one previous discussion [0]; does > > anyone know of others?) > > > > [0] > > https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00362.html > W.r.t. native-inputs, I think native-inputs should propagate > propagated-inputs, but not linked-inputs. Makes sense, doesn't it? > > -- Regards, Bengt Richter
Re: Rethinking propagated inputs?
Am Samstag, den 04.09.2021, 17:50 -0700 schrieb Sarah Morgensen: > Hi Liliana, > > (Efraim, I've Cc'd you since you're working on re-doing Rust inputs.) > > Liliana Marie Prikler writes: > > > Does anyone have an idea how we should handle propagations for the > > sake of pkg-config? Perhaps we could add "linked-inputs", which > > are added when building packages and environments when not using -- > > ad-hoc, but not when union-building profiles. WDYT? > > I know nothing about pkg-config, but such an input would help > simplify things for Go (and I think for Rust) since many inputs need > to be propagated only at build-time. To be fair, I wasn't not thinking about Go and Rust, which at least on the surface appear to have similar propagation semantics. I do however not know whether all currently propagated inputs from those two could be reclassified as linked-inputs. FWIW I don't think (most) Emacs, Python or Guile packages work that way, but I do know of at least one that would profit from having linked-inputs. > What do you think of "build-propagated-inputs"? We don't call things build-inputs here in Guix land, that's a no-no :P > (A quick search of the ML turned up one previous discussion [0]; does > anyone know of others?) > > [0] > https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00362.html W.r.t. native-inputs, I think native-inputs should propagate propagated-inputs, but not linked-inputs. Makes sense, doesn't it?
