bug#73816: python-django's manage.py tries to use a hard-coded python executable

bug#73816: python-django's manage.py tries to use a hard-coded python executable

[Gabriel Wicki]

The python-django package makes the admin utility create a manage.py
file with a hard-coded python interpreter.

  $ guix shell python python-django -- django-admin startproject foobar
  $ head -n 1 foobar/manage.py
  #!/gnu/store/my2j5bzapayk59971z2ryzlajdz569f9-python-toolchain-3.10.7/bin/python

I think this is wrong.  The interpreter line should be

  #!/usr/bin/env python3

Or am I wrong?

bug#73816: python-django's manage.py tries to use a hard-coded python executable

[Simon Tournier]

Hi,

On Tue, 15 Oct 2024 at 11:48, Gabriel Wicki <gabriel@erlikon.ch> wrote:

> The python-django package makes the admin utility create a manage.py
> file with a hard-coded python interpreter.
>
>   $ guix shell python python-django -- django-admin startproject foobar
>   $ head -n 1 foobar/manage.py
>   #!/gnu/store/my2j5bzapayk59971z2ryzlajdz569f9-python-toolchain-3.10.7/bin/python
>
> I think this is wrong.  The interpreter line should be
>
>   #!/usr/bin/env python3

Well, I don’t know if there is a rationale for this choice.  Somehow, my
understanding is: 1. python-django is byte-compiled using one specific
Python interpreter and 2. what is the guarantee that the whole code
byte-compiled with different Python interpreter will run?

Hence, that version of the specific Python interpreter is encoded.

Now, if the purpose of ’django-admin startproject foobar’ is to only
create generic configuration that does not depends on any Django or
Python version, then maybe it could be considered as wrong. :-)

Else I don’t know.  I remember having a similar discussion about a
similar Python tool but I am not able to find it back.

Cheers,
simon

bug#73816: python-django's manage.py tries to use a hard-coded python executable

[Gabriel Wicki]

Hi!

Thanks for your input!

On Tue, Dec 10, 2024 at 04:59:27PM +0100, Simon Tournier wrote:
> Now, if the purpose of ’django-admin startproject foobar’ is to only
> create generic configuration that does not depends on any Django or
> Python version, then maybe it could be considered as wrong. :-)
I think this is actually the case!  The `startproject' script
initializes a more or less empty project including said `manage.py'
script.  Now when starting and developing a Django project, all these
files will end up in VCS, might be packaged somewhat later on (if at
all) and executed on a different system, which may or may not have Guix
available.  Apart from that, hard-coding that script without any
guarantee whatsoever that this path exists in the system that will run
the code will more likely result in a failure than any kind of success.

If you have any idea on how to patch that and could point me in that
direction, I'll gladly send in a patch or two!

bug#73816: python-django's manage.py tries to use a hard-coded python executable

[Simon Tournier]

Hi,

On Wed, 11 Dec 2024 at 12:48, Gabriel Wicki <gabriel@erlikon.ch> wrote:

> If you have any idea on how to patch that and could point me in that
> direction, I'll gladly send in a patch or two!

It needs to replace the phases something like:

--8<---------------cut here---------------start------------->8---
1 file changed, 16 insertions(+)
gnu/packages/django.scm | 16 ++++++++++++++++

modified   gnu/packages/django.scm
@@ -99,6 +99,22 @@ (define-public python-django-4.2
                    (setenv "PYTHONPATH" "..")
                    (apply invoke "python" "runtests.py" test-flags))
                  (format #t "test suite not run~%"))))
+         (replace 'patch-source-shebangs
+           (lambda _
+             (for-each patch-shebang
+                       (find-files "."
+                                   (lambda (file stat)
+                                     (and (eq? 'regular (stat:type stat))
+                                          (not (string-suffix? "py-tpl" file))))
+                                   #:stat lstat))))
+         (replace 'patch-generated-file-shebangs
+           (lambda _
+             (for-each patch-shebang
+                       (find-files "."
+                                   (lambda (file stat)
+                                     (and (eq? 'regular (stat:type stat))
+                                          (not (string-suffix? "py-tpl" file))))
+                                   #:stat lstat))))
          ;; XXX: The 'wrap' phase adds native inputs as runtime dependencies,
          ;; see <https://bugs.gnu.org/25235>.  The django-admin script typically
          ;; runs in an environment that has Django and its dependencies on
--8<---------------cut here---------------end--------------->8---

Feel free to submit a patch. :-)

Cheers,
simon