[RTEMS Project] #4037: Python script distribution standardisation

RTEMS trac trac at rtems.org
Tue Aug 4 09:11:32 UTC 2020


#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):

 Seems that I misinterpreted the intention of the ticket. You asked:

 > Do we assume #! /usr/bin/env python will always work in our script and
 we make sure we are python2 and python3 clean for user installed commands?
 >
 > If a user does not have a python command installed by default do we
 document how to install one or do we document using a virtualenv?
 >
 > A simple shebang is cleaner for us to maintain however it added an extra
 dependency we need to document.

 From my point of view: As long as waf needs `python`, we can assume it for
 our scripts too. So we have to document that anyway as soon as we switch
 to `waf` for all core repos.

 From what you wrote we have to make sure that our scripts work with
 `python2` and `python3` anyway. I would reject a `python2` only version
 with it beeing no maintained anymore and slowly removed from distributions
 and you don't like a `python3` only version.

 The alternative would be to add a shell wrapper around `waf` too. But do
 we really want to maintain that with all edge cases? And again: That adds
 a fixed dependency to a shell. Without a wrapper we might be able to have
 packages for Windows that only contain a binary toolchain and a python
 installation. That could be useful for big teams that want to build the
 toolchain only on one host and distribute it in binary form to all
 developers.

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


More information about the bugs mailing list