Open Stack

Excerpts from Tim Simmons's message of 2016-05-09 18:29:30 +0000:
> > The point here though, is that the versions of Python that OpenStack
> > has traditionally supported have been directly tied to what the Linux
> > distributions carry in their repositories (case in point, Python 2.6
> > was dropped from most things as soon as RHEL7 was available with Python
> > 2.7). With Go, there might need to be similar restrictions.
> 
> I'm not sure about this, backwards compatibility in Go (at least in the last year) has been good
> for me.
> 
> But because like you say, you get a statically-linked binary, you don't need to
> worry about some version of anything the distro is packaging because your binary
> will run anywhere.
> 
> If you're looking to compile the code from scratch, it's intentionally simple to install the
> compiler, and there isn't any reason that you couldn't install multiple versions simply.

I think the idea is to avoid having a compile-time dependency on a version
that isn't part of what the distros package (and therefore have available
for building packages of the software we've written). We push them hard
on library dependencies, but try to be flexible with language tools.
That's why we waited to drop python 2.6 support until everyone had at
least 2.7, for example.

Doug

> 
> >> I think you'll find that being able to embed a higher performance language inside python will be much
> >> easier to do for optimizing a function or two rather then deal with having a separate server have to be created,
> >> authentication be added between the two, and marshalling/unmarshalling the data to and from it to optimize one little piece.
> >> Last I heard, you couldn't just embed go in python. C/C++ is pretty easy to do. 
> >> Maybe I'm wrong and its possible to embed go now. Someone, please chime in if you know of a good way.
> 
> There isn't a good way to embed Go (as far as I know), but I'd argue that for a relatively isolated use case (like Graham described
> of ours), it's better to just do the thing in Go than coerce C into Python. It'd introduce less risk and complexity than using Cython, imho.
> But I guess if you know C and not Go, that could be arguable.
> 
> Tim Simmons
> ________________________________________
> From: Clint Byrum <clint at fewbar.com>
> Sent: Monday, May 9, 2016 1:15 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [tc] supporting Go
> 
> Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700:
> > On Mon, 9 May 2016 09:06:02 -0400
> > Rayson Ho <raysonlogin at gmail.com> wrote:
> >
> > > Since the Go toolchain is pretty self-contained, most people just follow
> > > the official instructions to get it installed... by a one-step:
> > >
> > > # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
> >
> > I'm pretty certain the humanity has moved on from this sort of thing.
> > Nowadays "most people" use packaged language runtimes that come with
> > the Linux they're running.
> >
> 
> Perhaps for mature languages. But go is still finding its way, and that
> usually involves rapid changes that are needed faster than the multi-year
> cycle Linux distributions offer.
> 
> Also worth noting, is that go is not a "language runtime" but a compiler
> (that happens to statically link in a runtime to the binaries it
> produces...).
> 
> The point here though, is that the versions of Python that OpenStack
> has traditionally supported have been directly tied to what the Linux
> distributions carry in their repositories (case in point, Python 2.6
> was dropped from most things as soon as RHEL7 was available with Python
> 2.7). With Go, there might need to be similar restrictions.
>