unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Attila Lendvai <attila@lendvai.name>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: avoid wrapper scripts when possible
Date: Wed, 08 Sep 2021 12:39:55 +0200	[thread overview]
Message-ID: <bd25681cf3e9665a845ec61785de53dbb5915061.camel@telenet.be> (raw)
In-Reply-To: <R6RFjnkR5pY7GYiTIxWLK2EvPj1J717_UPN6s1n-sKsSpxFAkgcM_UQmZi7pPILgDZzHx2Ymw2C5aKWN55jsgHUCfg1CDLAbA8qE5I4FKCo=@lendvai.name>

[-- Attachment #1: Type: text/plain, Size: 2841 bytes --]

Attila Lendvai schreef op wo 08-09-2021 om 09:20 [+0000]:
> thanks for the ideas Maxime!
> 
> 
> > You could patch trezor-agent with something like
> > 
> > Python syntax might be incorrect
> > ================================
> > 
> > if sys.argv[0] == ".trezor-gpg'
> > sys.argv[0] = "trezor-gpg"
> > device_name = os.path.basename(sys.argv[0]).rsplit('-',1)[0]
> > 
> > Would that work?
> 
> most probably, but i thought first i'll pursue a more general fix for
> this. i will fall back to just patching upstream if i fail.
> 
> 
> > FWIW, there's 'wrap-program' and there is 'wrap-script'.
> > 
> > wrap-script is less likely to cause errors here (it doesn't rename the executable)
> > but less general. Maybe wrap-script can be used instead of wrap-program?
> 
> not sure how to do this. looking at python-build-system.scm it looks
> like there is no way to tell it to use wrap-script, so i went ahead
> and just changed the wrap-program call to wrap-script globally, and
> gave it a try.

Are you referring to the lines

    (for-each (lambda (dir)
                (let ((files (list-of-files dir)))
                  (for-each (cut wrap-program <> var)
                            files)))
              bindirs)

in the procedure 'wrap' from (guix build python-build-system)?

> the first error i encountered was in the package called scons. it has
> .bat files that wrap-script fails on. if i delete them in a snippet,
> then scons' own build system errors out.

The .bat are only for Windows, so you could remove them after the 'install'
phase or before the 'wrap' phase.  They seem to be useless on GNU/{Linux,Hurd}.

> any hints on how to proceed from here?

Instead of modifying 'wrap', you could replace the 'wrap' phase with
something like

  `(#:phases
    (modify-phases %standard-phases
      (replace 'wrap
        (lambda _
          ... customised wrapping code ...))))

Also, replacing wrap-program with wrap-script globally won't work
because wrap-script is less general, it only spports python, R,
perl and bash.  So something like

  (define (wrap-script-or-program ...)
    (if it-uses-python-or-ruby-or...
        (wrap-script ...)
        (wrap-program ...)))

may be required.

> was this what you meant at all?
> 
> would it be a worthwhile improvement to hack my way through this path
> at all?

There were some changes on core-updates to reduce double-wrapping,
so possibly it's already solved.

> shall i try to make it configurable from the package's definition,
> change the default, and force it back to wrap-program for packages
> that fail with wrap-script?

Perhaps try something like 'wrap-script-or-program' first?  That should
reduce the number of package definitions that need to be adjusted.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

  reply	other threads:[~2021-09-08 10:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07 18:52 avoid wrapper scripts when possible Attila Lendvai
2021-09-07 20:41 ` Maxime Devos
2021-09-08  9:20   ` Attila Lendvai
2021-09-08 10:39     ` Maxime Devos [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-09-24 21:38 John Kehayias
2017-11-02 21:31 Ricardo Wurmus
2017-11-03 18:54 ` Christopher Baines
2017-11-03 19:22   ` Jan Nieuwenhuizen
2017-11-03 21:17   ` Ricardo Wurmus
     [not found]     ` <874lqbghlz.fsf@elephly.net>
2017-11-03 22:41       ` Ricardo Wurmus
2017-11-05 11:10     ` Hartmut Goebel
2017-11-04 21:42   ` Eric Bavier
2017-11-04 10:12 ` Hartmut Goebel
     [not found]   ` <87tvy9ptge.fsf@elephly.net>
2017-11-05 11:00     ` Hartmut Goebel
2017-11-05 17:06       ` Ludovic Courtès
2017-11-06 15:53 ` Dave Love

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=bd25681cf3e9665a845ec61785de53dbb5915061.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=attila@lendvai.name \
    --cc=guix-devel@gnu.org \
    /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).