On Wed, Aug 24, 2016 at 4:46 PM, Allen Wittenauer <[email protected]>
wrote:

>
> > On Aug 24, 2016, at 3:49 PM, Andrew Wang <[email protected]>
> wrote:
> > My reasoning here has been that this tool will primarily be run by
> release
> > managers, and RMs are very likely to have Python 2.7 on their machine.
>
>         Whereas I believe the opposite: there's a good chance if one is
> the RM for enterprise software, the machine you are building on probably
> doesn't have python 2.7 on it because you aren't doing this work on your
> desktop!  It's extremely common to have build servers that are several OS
> revs behind because software tends to be more upwardly compatible....
>
> > ASF infra and servers in general are not really a target.
>
>         Umm, yeah, they kind of are. While there are certainly issues with
> them, they do serve as sort of a model of what is out in the real world.
> It's old and crufty and that's how a lot of software is built.  Where
> people build software is *exactly* our target.
>
>         Here's a fun anecdote.  Firefox v48 is the first version to drop
> support for Mac OS X 10.6, 10.7, and 10.8.  This means they were almost
> certainly building on 10.6.  So up until earlier this year, they were using
> a 7 year old OS that most definitely didn't have python 2.7 on it by
> default. Mozilla, by many accounts, would be considered quite aggressive
> but they can get away with it because they are targeting the desktop.
>
>
I think we're talking past each other here, since this is not a build tool.
It's an API checking tool. It only needs to be run on a developer's
computer, not all boxes at ASF. And, like I've been saying, you can just
install Python 2.7 like you would any other dependency. RDM requires `pip
install python-dateutils` for instance.


> > Maybe one day if
> > we want to run this as part of precommit, but then it can be optional
> like
> > gradle and docker.
>
>
>         It sends really bizarre mixed messages if one tool has different
> python requirements than another just because someone wanted to use a
> different option parsing library.


I don't know about "really bizzare"; this is the same problem as any
external dependency (e.g. python-dateutils).

The real issue here is the lack of a standardized runtime environment. Is
there build/packaging for Yetus? Some of this could be handled by wrappers
that created virtualenvs or downloaded conda as appropriate.

Reply via email to