Type Hinting in Saltstack

[Joseph Lorenzini]

Hi all,

So it looks like Von Rossum is planning on implementing a form of optional static typing in python 3.5.

https://www.python.org/dev/peps/pep-0484/

I know that static vs dynamic debate becomes close to a religious war. I am going to try not to reopen that debate. But I am curious to know if the salstack dev community is open to considering this once python 3 support is implemented. 

Thanks,

Joe 

[Colton Myers]

I won't speak in absolutes, but it seems very unlikely to me. Even once we have python 3 support, we must support Python 2.6 for the foreseeable future, as RHEL 6 will be supported for what feels like forever.

--
Colton Myers
Platform Engineer, SaltStack
@basepi on Github/Twitter/IRC

> --
> You received this message because you are subscribed to the Google Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Les Mikesell]

On Tue, Mar 24, 2015 at 3:35 PM, Colton Myers <colton...@gmail.com> wrote:
> I won't speak in absolutes, but it seems very unlikely to me. Even once we have python 3 support, we must support Python 2.6 for the foreseeable future, as RHEL 6 will be supported for what feels like forever.
>

Yeah, those computers that just keep running with simple updates for a
decade or more are just so annoying...

--
Les Mikesell
lesmi...@gmail.com

[Joseph Lorenzini]

Ohhh....so does that mean when salt moves over to python 3, the team will have to maintain python 2 compatible code base even though its running on python 3? That sounds horrible....

Joe 

[Tim O'Guin]

That's exactly what it means.

[Les Mikesell]

On Thu, Mar 26, 2015 at 8:22 AM, Joseph Lorenzini <jal...@gmail.com> wrote:
> Ohhh....so does that mean when salt moves over to python 3, the team will
> have to maintain python 2 compatible code base even though its running on
> python 3? That sounds horrible....
>

Yes, but that's hardly a surprise. Makes you wonder why people
choose a language that does not make backwards compatibility a
priority for anything they expect to support for any length of time.

--
Les Mikesell
lesmi...@gmail.com

[Colton Myers]

Yep, it's a bummer.

> Yes, but that's hardly a surprise.   Makes you wonder why people
> choose a language that does not make backwards compatibility a
> priority for anything they expect to support for any length of time.

They've only broken backwards compatibility once in how many years? It does make life difficult, but at the same time it's hard to move forward when you're crippled by legacy requirements. *shrugs* Guess we'll see where it goes in the next 5-10 years. But I love Python enough to work around issues like this. =P

--

Colton Myers

Platform Engineer, SaltStack

@basepi on Twitter/Github/IRC

[Les Mikesell]

On Thu, Apr 2, 2015 at 3:20 PM, Colton Myers <colton...@gmail.com> wrote:
> Yep, it's a bummer.
>
>> Yes, but that's hardly a surprise. Makes you wonder why people
>> choose a language that does not make backwards compatibility a
>> priority for anything they expect to support for any length of time.
>
> They've only broken backwards compatibility once in how many years?

Well, every time I've had to deal with any code.. Going back to some
instance of mailman I hand-installed before it was packaged on some
instance of RedHat before it was RHEL. Maybe 2002-ish. Whenever
the mailman code or the system python updated I'd have to track down
some weirdness in a language I didn't like...

> It does
> make life difficult, but at the same time it's hard to move forward when
> you're crippled by legacy requirements. *shrugs* Guess we'll see where it
> goes in the next 5-10 years. But I love Python enough to work around issues
> like this. =P

But if new rev's won't run your code, how can you like it,
particularly if you know it is going to someday need to install an
update that will break itself unless you can divorce the salt
installation from the system packages.

--
Les Mikesell
lesmi...@gmail.com

[Colton Myers]

> It does
> make life difficult, but at the same time it's hard to move forward when
> you're crippled by legacy requirements. *shrugs* Guess we'll see where it
> goes in the next 5-10 years. But I love Python enough to work around issues
> like this. =P

But if new rev's won't run your code, how can you like it,
particularly if you know it is going to someday need to install an
update that will break itself unless you can divorce the salt
installation from the system packages.

Guess we should have just written salt in Perl 6...

Anyway, discussion about python 2 vs 3 rarely goes to productive places, so I'm not going to comment on it more. But we do eventually plan to support both python 2 and python 3, and retain python 2 support for the foreseeable future. That way salt will work everywhere.

We can't (read: won't) divorce it from system packages. We don't want to get into the business of compiling python 2.7 (or python 3) for all our supported platforms.

[Les Mikesell]

On Thu, Apr 2, 2015 at 4:05 PM, Colton Myers <colton...@gmail.com> wrote:
>
> Guess we should have just written salt in Perl 6...

I think the perl guys are smart enough that no one will ever attempt
to replace perl5 with perl6 in a way that doesn't allow them to run
concurrently for an indefinite length of time. And perl versions 1
through 5 have been spectacular about backwards compatibility, with
the the introduction of interpolation of @ in double-quoted strings in
perl5 being about the only thing that you might have to fix in old
code.

> Anyway, discussion about python 2 vs 3 rarely goes to productive places, so
> I'm not going to comment on it more. But we do eventually plan to support
> both python 2 and python 3, and retain python 2 support for the foreseeable
> future. That way salt will work everywhere.
>
> We can't (read: won't) divorce it from system packages. We don't want to get
> into the business of compiling python 2.7 (or python 3) for all our
> supported platforms.

It just seems wrong for a system that you expect to manage your
machines to be able to be broken by this dependency. Is there perhaps
a way you could script the necessary steps to make it an
optional-but-standardized installation step to include a
frozen/embedded python version? That way only the people who
distrust their system-packaged updates will do it, but it will still
be a well-understood configuration.

--
Les Mikesell
lesmi...@gmail.com

[Colton Myers]

> It just seems wrong for a system that you expect to manage your
> machines to be able to be broken by this dependency.  Is there perhaps
> a way you could script the necessary steps to make it an
> optional-but-standardized installation step to include a
> frozen/embedded  python version?   That way only the people who
> distrust their system-packaged updates will do it, but it will still
> be a well-understood configuration.

This is how we do our windows install. And I want to say that at least one of the sets of packages works this way (suse maybe?)

Thanks for the request, frozen installs are something we may put some effort into in the future.

--

Colton Myers

Platform Engineer, SaltStack

@basepi on Twitter/Github/IRC

--
   Les Mikesell
     lesmi...@gmail.com