bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Jelle Licht]

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

Hi,

I had some problems getting current ansible package to work. It seems that
the bin/ansible script which is created as part of the python-build-system
via a call to `wrap-program' interferes with certain expectations ansible
has regarding how it and its subcommands are called.

This mechanism does not work well with our generated created .ansible-real.
See [1] for a similar issue that has since been worked around in the newest
version of ansible.

For now, I have a similar workaround that add some guix-specific checks to
ansible looking for being called as .ansible-real, though I do consider
this a hack. This problem is indicative of a bigger issue: the fact that
wrap-program currently leads to subtle bugs for lots of scripts. There has
been some noise on #guix about solving this problem in general.

Thanks,
Jelle

[1]: https://github.com/ansible/ansible/issues/22261

[-- Attachment #2: Type: text/html, Size: 1076 bytes --]

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Ludovic Courtès]

Jelle Licht <jlicht@fsfe.org> skribis:

> I had some problems getting current ansible package to work. It seems that
> the bin/ansible script which is created as part of the python-build-system
> via a call to `wrap-program' interferes with certain expectations ansible
> has regarding how it and its subcommands are called.
>
> This mechanism does not work well with our generated created .ansible-real.
> See [1] for a similar issue that has since been worked around in the newest
> version of ansible.
>
> For now, I have a similar workaround that add some guix-specific checks to
> ansible looking for being called as .ansible-real, though I do consider
> this a hack. This problem is indicative of a bigger issue: the fact that
> wrap-program currently leads to subtle bugs for lots of scripts. There has
> been some noise on #guix about solving this problem in general.

For the record, the discussion is visible here:
<https://gnunet.org/bot/log/guix/2017-05-02#T1370586>.

I think it’s bad for a program to rely on argv[0], but I also think
those .thing-real are kinda ugly.  :-)

Ludo’.

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Jelle Licht]

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

The current ansible package is still brokenin the same way.

Is there already an acceptable way of working around this problem?
Otherwise I could send my (extremely hacky) workaround that adds a specific
condition in the ansible source code to check for .ansible-real.

Thanks,
Jelle

2017-05-03 12:04 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:

> Jelle Licht <jlicht@fsfe.org> skribis:
>
> > I had some problems getting current ansible package to work. It seems
> that
> > the bin/ansible script which is created as part of the
> python-build-system
> > via a call to `wrap-program' interferes with certain expectations ansible
> > has regarding how it and its subcommands are called.
> >
> > This mechanism does not work well with our generated created
> .ansible-real.
> > See [1] for a similar issue that has since been worked around in the
> newest
> > version of ansible.
> >
> > For now, I have a similar workaround that add some guix-specific checks
> to
> > ansible looking for being called as .ansible-real, though I do consider
> > this a hack. This problem is indicative of a bigger issue: the fact that
> > wrap-program currently leads to subtle bugs for lots of scripts. There
> has
> > been some noise on #guix about solving this problem in general.
>
> For the record, the discussion is visible here:
> <https://gnunet.org/bot/log/guix/2017-05-02#T1370586>.
>
> I think it’s bad for a program to rely on argv[0], but I also think
> those .thing-real are kinda ugly.  :-)
>
> Ludo’.
>

[-- Attachment #2: Type: text/html, Size: 2163 bytes --]

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Ludovic Courtès]

Hi,

Jelle Licht <jlicht@fsfe.org> skribis:

> The current ansible package is still brokenin the same way.
>
> Is there already an acceptable way of working around this problem?
> Otherwise I could send my (extremely hacky) workaround that adds a specific
> condition in the ansible source code to check for .ansible-real.

For now I think we have to go with the hack.  Make sure to add a comment
linking to this bug report.

Thanks,
Ludo’.

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Danny Milosavljevic]

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

Just a heads-up, if we make the Python wrap-program do the wrapping inline (bug# 29856), this problem here will also vanish.

See https://lists.gnu.org/archive/html/guix-devel/2017-11/msg00027.html for the newest possible approach.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Ricardo Wurmus]

ludo@gnu.org (Ludovic Courtès) writes:
> Jelle Licht <jlicht@fsfe.org> skribis:
>
>> The current ansible package is still brokenin the same way.
>>
>> Is there already an acceptable way of working around this problem?
>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>> condition in the ansible source code to check for .ansible-real.
>
> For now I think we have to go with the hack.  Make sure to add a comment
> linking to this bug report.

There is a way to get around this.  It’s presented in #29951:

    https://issues.guix.info/issue/29951

Open issues with this include a hard-coded store prefix, but it’s no big
obstacle.  Should we give this a try on core-updates?

[bug#29951] bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Ricardo Wurmus]

ludo@gnu.org (Ludovic Courtès) writes:
> Jelle Licht <jlicht@fsfe.org> skribis:
>
>> The current ansible package is still brokenin the same way.
>>
>> Is there already an acceptable way of working around this problem?
>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>> condition in the ansible source code to check for .ansible-real.
>
> For now I think we have to go with the hack.  Make sure to add a comment
> linking to this bug report.

There is a way to get around this.  It’s presented in #29951:

    https://issues.guix.info/issue/29951

Open issues with this include a hard-coded store prefix, but it’s no big
obstacle.  Should we give this a try on core-updates?

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Arun Isaac]

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


> The current ansible package is still brokenin the same way.

FWIW, I fixed our ansible package in
https://issues.guix.info/issue/33777 . This is not a general solution,
but at least our ansible package works at the moment.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>> Jelle Licht <jlicht@fsfe.org> skribis:
>>
>>> The current ansible package is still brokenin the same way.
>>>
>>> Is there already an acceptable way of working around this problem?
>>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>>> condition in the ansible source code to check for .ansible-real.
>>
>> For now I think we have to go with the hack.  Make sure to add a comment
>> linking to this bug report.
>
> There is a way to get around this.  It’s presented in #29951:
>
>     https://issues.guix.info/issue/29951
>
> Open issues with this include a hard-coded store prefix, but it’s no big
> obstacle.  Should we give this a try on core-updates?

Definitely, please do!

Thanks,
Ludo’.

[bug#29951] bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>> Jelle Licht <jlicht@fsfe.org> skribis:
>>
>>> The current ansible package is still brokenin the same way.
>>>
>>> Is there already an acceptable way of working around this problem?
>>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>>> condition in the ansible source code to check for .ansible-real.
>>
>> For now I think we have to go with the hack.  Make sure to add a comment
>> linking to this bug report.
>
> There is a way to get around this.  It’s presented in #29951:
>
>     https://issues.guix.info/issue/29951
>
> Open issues with this include a hard-coded store prefix, but it’s no big
> obstacle.  Should we give this a try on core-updates?

Definitely, please do!

Thanks,
Ludo’.

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>> Jelle Licht <jlicht@fsfe.org> skribis:
>>
>>> The current ansible package is still brokenin the same way.
>>>
>>> Is there already an acceptable way of working around this problem?
>>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>>> condition in the ansible source code to check for .ansible-real.
>>
>> For now I think we have to go with the hack.  Make sure to add a comment
>> linking to this bug report.
>
> There is a way to get around this.  It’s presented in #29951:
>
>     https://issues.guix.info/issue/29951

BTW, there’s also this patch series on this topic:

  https://issues.guix.info/issue/27003

What to do?

Ludo’.

[bug#29951] bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>> Jelle Licht <jlicht@fsfe.org> skribis:
>>
>>> The current ansible package is still brokenin the same way.
>>>
>>> Is there already an acceptable way of working around this problem?
>>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>>> condition in the ansible source code to check for .ansible-real.
>>
>> For now I think we have to go with the hack.  Make sure to add a comment
>> linking to this bug report.
>
> There is a way to get around this.  It’s presented in #29951:
>
>     https://issues.guix.info/issue/29951

BTW, there’s also this patch series on this topic:

  https://issues.guix.info/issue/27003

What to do?

Ludo’.

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Brice Waegeneire]

Hello,

Arun Isaac <arunisaac@systemreboot.net> writes:
> FWIW, I fixed our ansible package in
> https://issues.guix.info/issue/33777 . This is not a general solution,
> but at least our ansible package works at the moment.

If this bug is about ansible malfunctioning then it should be closed,
Arun fixed it in 01cb4d47570c38812492bbc331b7b818e1b69fbb. I've tested
it myself successfully with the command from the IRC report[0] (linked
in the merged issue[2]).
On the other hand If it's about fixing it with the new wrap-script from
Ricardo I can send a patch, but the derivation will need guile as a new
input.

[0]: http://logs.guix.gnu.org/guix/2018-04-28.log#013741
[1]: https://issues.guix.info/issue/31299

Brice.

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Jelle Licht]

Hi

Brice Waegeneire <brice@waegenei.re> writes:

> Hello,
>
> Arun Isaac <arunisaac@systemreboot.net> writes:
>> FWIW, I fixed our ansible package in
>> https://issues.guix.info/issue/33777 . This is not a general solution,
>> but at least our ansible package works at the moment.
>
> If this bug is about ansible malfunctioning then it should be closed,
> Arun fixed it in 01cb4d47570c38812492bbc331b7b818e1b69fbb. I've tested
> it myself successfully with the command from the IRC report[0] (linked
> in the merged issue[2]).
> On the other hand If it's about fixing it with the new wrap-script from
> Ricardo I can send a patch, but the derivation will need guile as a new
> input.

I would be okay with closing it, as ansible works fine right now. If the
current solution is deemed too brittle, or if the intent behind the new
wrap-script is that we use it everywhere we can, then not of course.

- Jelle