[RTEMS Project] #4037: Python script distribution standardisation

[RTEMS trac]

#4037: Python script distribution standardisation
-------------------------+---------------------
 Reporter:  Chris Johns  |       Owner:  (none)
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:  6.1
Component:  admin        |     Version:  6
 Severity:  normal       |  Resolution:
 Keywords:               |  Blocked By:
 Blocking:               |
-------------------------+---------------------

Comment (by Christian Mauderer):

 I'm currently a bit undecided. Both methods have advantages and
 disadvantages.

 Points that could be a reason _not_ to use a wrapper:
 - '''One important point''': We start to use `waf` everywhere. `waf`
 starts with a `#!/usr/bin/env python`. So it assumes that `python` exists.
 That means as soon as a user wants to build something with `waf` he needs
 a `python`. I don't think that we want to provide a wrapper for `waf`?
 - Although you did a great job making it as simple as possible: A wrapper
 adds complexity. How many edge cases are missed in the wrappers? For
 example: If you try to call one of the source builder commands using a
 soft link in another directory, the `$(dirname $0)` of the wrapper will
 fail.
 - Every supported system has to provide a `/bin/sh` and a `dirname`
 command. Can we be sure that's the case? What about Windows? If we enforce
 the wrapper we will always need a mingw or msys for Windows. If we remove
 it it might be possible to build RTEMS with only a python installation
 somewhen in the future (although you still need a cross-compiled gcc or
 llvm).
 - Do we really want to support multiple python versions on the long term?
 It might start to get really complicated to test all relevant
 configurations. By the way: Does buildbot use `python2`, `python3` or
 both?

 Points that could be a good reason for using a wrapper:
 - Do all our scripts work with `python3` already? The wrapper of the
 source builder currently defaults to `python2`. So most likely it is
 nearly untested with `python3`.
 - I think I had trouble building rtems-docs with python3 in the past (and
 I always have been too lazy to fix them - sorry). That means that
 currently _not_ everything is ready to work with all python versions. A
 wrapper could select the best one. But that also means we basically depend
 on `python2` _and_ `python3` to be installed.
 - We will have a really simple possibility to switch to `python4` when it
 comes out.
 - On systems without a `python` it will definitively make it simpler.

 Background questions:
 - Do we know of distributions that don't provide a `python` (without
 version number) command?

--
Ticket URL: <http://devel.rtems.org/ticket/4037#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project