guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#52117] [core-updates-frozen] [PATCH 0/6] Fix Julia packages.


From: zimoun
Subject: [bug#52117] [core-updates-frozen] [PATCH 0/6] Fix Julia packages.
Date: Mon, 29 Nov 2021 15:10:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi Maxim,

On Sat, 27 Nov 2021 at 21:57, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> No, it would invoke julia with the following argv list: "julia"
> "-depwarn=yes" "" [...];
>
> My point is that invoke is equivalent to doing an execlp system call;
> and the arguments get passed as a list (including that empty string
> argument when parallel-tests? is #f).  Whether this works or not is up
> to the application, so I'd suggest not relying on it.  Consider for
> example:
>
> (execlp "python" "python" "" "-c" "print('hello')")
> /gnu/store/cwqv4z5bvb5x6i0zvqgc1j1dnr6w9vp8-profile/bin/python: can't
> find '__main__' module in
> '/home/maxim/src/guix-core-updates-next/gnu/packages/'

Thanks for the explanations.


> It fails because it interprets the empty string argument as the current
> directory, apparently.  If that works with the above Julia invocation,
> that's great, but it doesn't make it cleaner in my opinion :-).

Indeed, and it is expected to fail because:

--8<---------------cut here---------------start------------->8---
def _get_main_module_details(error=ImportError):
    # Helper that gives a nicer error message when attempting to
    # execute a zipfile or directory by invoking __main__.py
    main_name = "__main__"
    try:
        return _get_module_details(main_name)
    except ImportError as exc:
        if main_name in str(exc):
            raise error("can't find %r module in %r" %
                              (main_name, sys.path[0]))
        raise
--8<---------------cut here---------------end--------------->8---

It allows to do:

        $ mkdir /tmp/foo
        $ echo print(42) > /tmp/foo/__main__.py
        $ python /tmp/foo

Therefore, this

        $ python '' -c '0'

just fails.  Contrary to,

        $ cd /tmp/foo
        $ python '' -c '0'

which just passes.  To me, it is an oddity of the Python command-line
which silently accepts a path; it is not documented by “python -h”.

Anyway, I agree that the behaviour when passing "" is up to the
application, therefore it should be avoided.


Cheers,
simon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]