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!