[PATCH 1 of 3 v2] hooks: add intermediate function _get_python_executable

[Mads Kiilerich]

On 4/6/19 8:25 PM, Thomas De Schampheleire wrote:
>
> El jue., 4 abr. 2019 a las 0:41, Mads Kiilerich (<mads at kiilerich.com 
> <mailto:mads at kiilerich.com>>) escribió:
>
>     > @@ -734,11 +738,11 @@ class ScmModel(object):
>     >           if not os.path.isdir(loc):
>     >               os.makedirs(loc)
>     >
>     > -        tmpl_post = "#!/usr/bin/env %s\n" % sys.executable or
>     'python2'
>     > +        tmpl_post = "#!/usr/bin/env %s\n" %
>     self._get_python_executable()
>
>
>     Also, can you remind me (and perhaps clarify in code): #! paths
>     are only
>     used on posix. How does this work on Windows? Or is that covered by
>     tribal "Don't use Git on Windows" knowledge? Especially: With git
>     having
>     one hardcoded executable name for each hook, how does it generally
>     work
>     finding the right hook script interpreter when Windows doesn't use
>     #! paths?
>
>
> After some searching, it seems that git hooks on windows magically 
> work with #!/bin/bash, and that to get python hooks working you should 
> create a shell wrapper script.
> See 
> https://stackoverflow.com/questions/9308119/git-cannot-execute-python-script-as-hook
> So if this is correct (I was too lazy to test it now) then git hooks 
> don't work yet on windows anyway. We could treat it as a future 
> feature to implement, but as there is no-one that requested it yet, I 
> guess it's not a very high priority.


Does that mean we have to differentiate different kinds of Git - msysgit 
and others?

Or should we for now realize that we don't really support/recommend 
virtualenv if hosting Git on Windows? Or perhaps ignore Git hosting on 
Windows for now? If we make that clear, some things might be simpler.


> Hm, I now realize that it's actually dulwich and not git that is 
> invoked, but as far as I can see it is just invoking the hook via 
> subprocess, so I think the conclusion remains.


The odd pygrack also plays an odd role in this.


>     (Also, AFAIK, /usr/bin/env is really mainly for searching in PATH
>     so we
>     don't have to specify full path. If we specify full paths, it thus
>     seems
>     a bit wrong to use env? That is an old thing that we don't have to
>     care
>     about now, but perhaps keep it in mind if it pops up now.)
>
>
> Yes, but if we fallback to 'python2' then we actually need 'env'. So, 
> maybe we should do something like self.get_python_executable() or 
> sys.executable or '/usr/bin/env python2'.


Yes, perhaps ideally something like that. But perhaps not necessarily now.

/Mads

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20190407/6ccd00d1/attachment-0001.html>