Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Forgot to add: ┌──┐ │ guile -c '(use-modules (ice-9 session))(apropos "env") │ ├──┤ │ (guile): getenv # │ │ (guile): environ # │ │ (guile): setenv # │ │ (guile): interaction-environment # │ │ (guile): putenv # │ │ (guile): unsetenv # │ └──┘ BTW, it would be really handy to be able to type guile -apropos rest of line as regex for the effect of ,a rest of line as regex in the guile repl -- Regards, Bengt Richter
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, Konrad, et al On +2019-12-17 10:14:12 +0100, Gábor Boskovits wrote: > Hello Konrad, > > Konrad Hinsen ezt írta (időpont: 2019. dec. > 17., Ke 7:52): > > > On 16/12/2019 23:09, Ludovic Courtès wrote: > > > So in a more algorithmic manner: > > >> 1. if ad-hoc and inputs-of is present at the same invocation: fail > > >> hard. (With an error like incompatible options present) > > >> 2. if only ad-hoc is present, then print a deprecation warning (yes, > > >> we could make this suspendable with an environment variable, like you > > >> described) > > >> 3. if only inputs-of present, then do the new behaviour. > > >> 4. if neither ad-hoc nor inputs-of present then > > >>a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > > >>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > > >> new behaviour. > > > That sounds like a good plan to me. > > > > > > #4 is the trickiest, and I think it’d be good to give users a bit of > > > time so they can start adjusting before deprecation is in effect. > > > > #4 is trickiest for another reason: there is no future-proof use of > > "guix environment" that works right now and will continue to work. Nor > > is there any way to see, when looking at a command line, whether it's > > old-style or new-style, if neither --ad-hoc nor --inputs-of are present. > > This means that all existing documentation (tutorials etc.) will become > > misleading in the future. Worse, even documentation written today, in > > full awareness of a coming change, can't do better than saying "watch > > out, this will do something else in the future". > > > > The first rule of backwards-compatibility is: never change the meaning > > of an existing valid command/API. Add new valid syntax, deprecate old > > valid syntax, but don't change the meaning of something that was and > > will be valid. > > I think it is important to consider context when talking about meaning. 1. the level and the interpreter of the command: The first level is usually the shell (typicallly bash) from logind, but there is systemd and/or shepherd before that, and there is bootloader and UEFI and before that also accepting and/or passing commands through to the kernel via the kernel command line (cf. cat /proc/cmdline ). The general pattern I mostly see for a given interpreter is verb -adverb* (-adjective-for: object-name)* sub-command? implicit-or-object-for-verb* Consider whether your new name reinforces a good convention or forks it. Consider whether proposed usage translates easily to a natural language explanation. Does guix have a cli design best practices doc, BTW? right now we are talking about the use case where verb=guix and subcommand=environment 2. project community conventions Specialized areas often have their own jargon and abbreviated refrences so an unfortunate choice of name can cause distracting disambiguation searches. Before settling on a new name xxx, even for a sub-command, I would say at least first do the following at the command line: which xxx xxx --version xxx --help info xxx man xxx apropos xxx #check for same prefix, case-insensitively, # e.g. env might be tempting, as seen in this thread :) --8<---cut here---start->8--- echo $PATH|tr : $'\n'|while read pdir;do (find "$pdir" -maxdepth 1 -iname "env*" 2>/dev/null);done --8<---cut here---end--->8--- # -name "*xxx*" may also be a good idea, but the prefix is most important # env* produces /usr/bin/env /usr/bin/envsubst guix search xxx guix package -A xxx wikipedia search on xxx, e.g. lynx -dump -force_html -nolist https://en.wikipedia.org/w/index.php?search=xxx |less You get the idea, I'm sure ;-) > > How about a more drastic measure: deprecate "guix environment" and > > introduce a new subcommand with the desired new behaviour? > > SGTM, with some caveats Good, since calling different things by the same name is always going to be problematic. Iffy, since calling the same thing by different names may reduce future naming options, and may muddy the peer-name namespace, so maybe consider using sub-commands or -adverb. > That is also the other option I was thinking about. Do you have any good > idea in mind as how to call it? Of course the classic guix environment2 > comes to my mind, but it does not look very appealing to me. > Me neither :) > > > > Cheers, > > > >Konrad. > > > Best regard, > g_bor > HTH in some way :) -- Regards, Bengt Richter
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Konrad, On Tue, 17 Dec 2019 at 07:52, Konrad Hinsen wrote: > > On 16/12/2019 23:09, Ludovic Courtès wrote: > > So in a more algorithmic manner: > >> 1. if ad-hoc and inputs-of is present at the same invocation: fail > >> hard. (With an error like incompatible options present) > >> 2. if only ad-hoc is present, then print a deprecation warning (yes, > >> we could make this suspendable with an environment variable, like you > >> described) > >> 3. if only inputs-of present, then do the new behaviour. > >> 4. if neither ad-hoc nor inputs-of present then > >>a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > >>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > >> new behaviour. > > That sounds like a good plan to me. > > > > #4 is the trickiest, and I think it’d be good to give users a bit of > > time so they can start adjusting before deprecation is in effect. > > #4 is trickiest for another reason: there is no future-proof use of > "guix environment" that works right now and will continue to work. Nor > is there any way to see, when looking at a command line, whether it's > old-style or new-style, if neither --ad-hoc nor --inputs-of are present. > This means that all existing documentation (tutorials etc.) will become > misleading in the future. Worse, even documentation written today, in > full awareness of a coming change, can't do better than saying "watch > out, this will do something else in the future". I do not understand what is the issue for the time-traveling if it is documented. Maybe I miss a point. It is not: "watch out, this will do something else in the future" but "watch out, this was doing something else in the past and the change happened the in ". First, I am not convinced that there is not so much scripts that will be broken. And second, I am not convinced neither that these very scripts need time-traveling. > The first rule of backwards-compatibility is: never change the meaning > of an existing valid command/API. Add new valid syntax, deprecate old > valid syntax, but don't change the meaning of something that was and > will be valid. I agree on the rule. But it is mitigated but the number of users and the popularity of the tool. ;-) > How about a more drastic measure: deprecate "guix environment" and > introduce a new subcommand with the desired new behaviour? Yes, it is probably the most adequate to do. But it is sad to loose the good name "guix environment"... and we know that naming is hard. ;-) What about "guix shell"? All the best, simon
Re: qt-build-system: prefix or suffix env-variables in wrap-program
Sorry for the late reply.
Hartmut Goebel writes:
> Am 11.12.19 um 21:25 schrieb Mikhail Kryshen:
>> So the correct way to extend XDG_DATA_DIRS would be
>>
>> export
>> XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:/gnu/store/…-kate-…"
>
> I'm quite confident, adding /usr/share etc. here as default would be
> wrong from a guix point of view: This would break isolation of
> environments. On a foreign distribution this would even give the foreign
> distribution's installation precedence over guix's.
The problem is that conforming programs treat empty or unset
XDG_DATA_DIRS as "/usr/local/share/:/usr/share/", for such programs
XDG_DATA_DIRS="" and XDG_DATA_DIRS="/usr/local/share/:/usr/share/" are
equivalent, and thus their extensions should be equivalent too. Empty
or unset XDG_DATA_DIRS already breaks isolation: when it is empty, it
means (according to the spec) that programs are supposed to refer to
/usr in the current environment. Because of this, I think that in pure
Guix environment XDG_*_DIRS variables should never be left unset (and so
/usr will not be referred to implicitly and will not appear in the
extended value).
Overriding the value (including the implicit
"/usr/local/share/:/usr/share/") will cause problems when wrapped
program launches a non-guix program from the host system (e.g. MUA
opening an attachment) that will inherit its environment.
> Anyway: Let me ask my question differently: Should the user be able to
> *overrule* or only to *extend* guix's installation?
Allowing to overrule will be problematic, because XDG_*_DIRS may be set
by the system and include directories with conflicting files (e.g. from
different version of the same program installed in the system profile or
in the host non-guix system).
So I suggest prefixing XDG_*_DIRS like this:
XDG_DATA_DIRS="/gnu/store/…:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"
So the added path gets higher priority, and the other paths are
preserved, including the implicit "/usr/local/share/:/usr/share/" in
case of initially empty variable.
--
Mikhail
signature.asc
Description: PGP signature
Re: Guix mirror: sourceware discussion report
Hi, On Sat, 14 Dec 2019 at 23:44, Ricardo Wurmus wrote: > > Well, how many people have a physical access to the MDC infrastructure? > > How many people are currently working for the MDC institute? > > To my knowledge, only Ricardo. > > So what will happen if Ricardo "leaves" (long vacation, change of job, > > bus attack, etc.). > > Mădălin also has physical access. Nice! I withdraw my proposal. Something as mirror.guix.gnu.org sounds sweet! :-) All the best, simon ps: I hope that nobody has taken my tiny proposal as a criticism of all the tough work done in Berlin. On the contrary, it was an attempt to help.
Re: Importers as independent packages?
On 2019-12-17 04:37, Martin Becze wrote: > Hello Guix, > I have been working on a recursive importer that uses semantic > versioning over on #38408. It relies on guile-semver. I'm not exactly > sure how to add guile-semver as a dependency to guix. But I'm also not > sure that I should. Importers will probably not be used by the majority > of end users so would it make sense to put the importers in their own > package? This would also nicely solve recursive-import-semver's problem > of being dependent on guile-semver. > > Also in the future it would be nice if the crate import could read from > a Cargo.toml directly (this will make importing things like alacritty > much easier since it is not crates.io), which would probably mean have > yet another dependency (guile-toml). What do you think about this Guix? > > Thanks, > -Martin Becze So I should say that I meant one package for all importers. Not one package per-importer, since they share several common files.
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Dec 17, 2019 7:34:17 AM Kyle Meyer : > G�bor Boskovits writes: > > > > Konrad Hinsen ezt �rta (id?pont: 2019. dec. > > 17., Ke 7:52): > > > [...] > > > > > > How about a more drastic measure: deprecate "guix environment" and > > > introduce a new subcommand with the desired new behaviour? > > > > > > > > That is also the other option I was thinking about. Do you have any good > > idea in mind as how to call it? Of course the classic guix environment2 > > comes to my mind, but it does not look very appealing to me. > > > > Perhaps "guix env"? > +1 for guix env
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Gábor Boskovits writes: > Konrad Hinsen ezt írta (időpont: 2019. dec. > 17., Ke 7:52): [...] >> How about a more drastic measure: deprecate "guix environment" and >> introduce a new subcommand with the desired new behaviour? >> > That is also the other option I was thinking about. Do you have any good > idea in mind as how to call it? Of course the classic guix environment2 > comes to my mind, but it does not look very appealing to me. Perhaps "guix env"?
Re: wrap-program –> wrap-script
Efraim Flashner writes: > On Wed, Dec 11, 2019 at 04:57:41PM +0100, Ricardo Wurmus wrote: […] >> I’ve just pushed a change to use wrap-script in one package. […] >> >> 2) we aren’t using wrap-script anywhere. I think a good use case would >> be the Python build system’s “wrap” phase where we currently use >> wrap-program. Most of the time we’d be dealing with Python scripts, so >> using wrap-script would be more appropriate here. > > It turns out we are using it in vpnc-scripts. Yes, that’s where I added it right before writing my email. -- Ricardo
Re: wrap-program –> wrap-script
On Wed, Dec 11, 2019 at 04:57:41PM +0100, Ricardo Wurmus wrote: > Hi Guix, > > I’ve just pushed a change to use wrap-script in one package. The > purpose of wrap-script is to wrap an executable without having to create > a separate wrapper shell script. It does this by prepending a Guile > script to the top of the file, which sets the environment variables and > then re-executes itself with the target interpreter (e.g. Python). > > I noticed two things: > > 1) wrap-script does not automatically pull in Guile as a dependency, so > if Guile isn’t among the inputs it will create a bad shebang. This > should be fixed on core-updates. I thought the build systems had an implicit guile in them. Looks like I had that exactly backwards. > > 2) we aren’t using wrap-script anywhere. I think a good use case would > be the Python build system’s “wrap” phase where we currently use > wrap-program. Most of the time we’d be dealing with Python scripts, so > using wrap-script would be more appropriate here. It turns out we are using it in vpnc-scripts. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Tk 8.6.10 cross-compilation.
Hello Marius, Since the update of Tk to 8.6.10 in core-updates, I have the following error when cross-compiling for aarch64: --8<---cut here---start->8--- aarch64-linux-gnu-gcc -O2 -pipe-Wl,--export-dynamic -shared -o libtk8.6.so tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkBusy.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o tkConsole.o tkCursor.o tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o tkSelect.o tkStyle.o tkUndo.o tkUtil.o tkVisual.o tkWindow.o tkButton.o tkEntry.o tkFrame.o tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkPanedWindow.o tkScale.o tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o tkImgPNG.o tkImgPPM.o tkImgPhoto.o tkImgPhInstance.o tkText.o tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o tkTextWind.o tkStubInit.o ttkBlink.o ttkButton.o ttkCache.o ttkClamTheme.o ttkClassicTheme.o ttkDefaultTheme.o ttkElements.o ttkEntry.o ttkFrame.o ttkImage.o ttkInit.o ttkLabel.o ttkLayout.o ttkManager.o ttkNotebook.o ttkPanedwindow.o ttkProgress.o ttkScale.o ttkScrollbar.o ttkScroll.o ttkSeparator.o ttkSquare.o ttkState.o ttkTagSet.o ttkTheme.o ttkTrace.o ttkTrack.o ttkTreeview.o ttkWidget.o ttkStubInit.o tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o tkUnixXId.o -lpthread -lX11 -ldl -lpthread -lm -L/gnu/store/69g2cklv99hin2cyvpamxdmxzxlr8l93-tcl-8.6.10/lib -ltclstub8.6 -Wl,-rpath,/gnu/store/r4ncs29n5a13dl79afglp2d1f2bmlakh-tk-8.6.10/lib:/gnu/store/69g2cklv99hin2cyvpamxdmxzxlr8l93-tcl-8.6.10/lib aarch64-linux-gnu-ld: /gnu/store/69g2cklv99hin2cyvpamxdmxzxlr8l93-tcl-8.6.10/lib/libtclstub8.6.a(strtoul.o): in function `strtoul': (.text+0x30): undefined reference to `TclIsSpaceProc' aarch64-linux-gnu-ld: libtk8.6.so: hidden symbol `TclIsSpaceProc' isn't defined aarch64-linux-gnu-ld: final link failed: bad value --8<---cut here---end--->8--- I opened a ticket on tk bug tracker. Would it be fine to revert tk to 8.6.9 version in the meantime? Thanks, Mathieu
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello Konrad, Konrad Hinsen ezt írta (időpont: 2019. dec. 17., Ke 7:52): > On 16/12/2019 23:09, Ludovic Courtès wrote: > > So in a more algorithmic manner: > >> 1. if ad-hoc and inputs-of is present at the same invocation: fail > >> hard. (With an error like incompatible options present) > >> 2. if only ad-hoc is present, then print a deprecation warning (yes, > >> we could make this suspendable with an environment variable, like you > >> described) > >> 3. if only inputs-of present, then do the new behaviour. > >> 4. if neither ad-hoc nor inputs-of present then > >>a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > >>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > >> new behaviour. > > That sounds like a good plan to me. > > > > #4 is the trickiest, and I think it’d be good to give users a bit of > > time so they can start adjusting before deprecation is in effect. > > #4 is trickiest for another reason: there is no future-proof use of > "guix environment" that works right now and will continue to work. Nor > is there any way to see, when looking at a command line, whether it's > old-style or new-style, if neither --ad-hoc nor --inputs-of are present. > This means that all existing documentation (tutorials etc.) will become > misleading in the future. Worse, even documentation written today, in > full awareness of a coming change, can't do better than saying "watch > out, this will do something else in the future". > > The first rule of backwards-compatibility is: never change the meaning > of an existing valid command/API. Add new valid syntax, deprecate old > valid syntax, but don't change the meaning of something that was and > will be valid. > > How about a more drastic measure: deprecate "guix environment" and > introduce a new subcommand with the desired new behaviour? > That is also the other option I was thinking about. Do you have any good idea in mind as how to call it? Of course the classic guix environment2 comes to my mind, but it does not look very appealing to me. > > > Cheers, > >Konrad. > Best regard, g_bor > > > >
